Open wjhuggins opened 1 month ago
ReflectionUsingPrepare expects the prepare_gate
to be a sublcass of PrepareOracle, we should probably enforce all "Prepare" bloqs to inherit from PrepareOracle, but currently there's a bit of a gap.
That makes sense. I'll repeat what I said in chat though: it's a little funny to think of ReflectionViaPrepare as something inherently tied to the LCU context since reflections about a state are useful in a lot of places.
That's a good point. We should probably think about this a bit more carefully.
To be a little provocative: the whole idea of using the Python class hierarchy to define abstract properties that influence the quantum signature of a bloq is misguided. You can imagine a world where we have a "quantum interface" which says something like "implementers of the state prep interface has one register named 'select'" and something like #789 can auto-partition
how do you enforce the quantum interface if not using some abstract base class? I'm on board with 789 though.
The same way we enforce quantum type checking, which is not by using the python type checker. The abc.ABCMeta
metaclass runs some code when the class definition is encountered by the python interpreter that goes through and checks all the methods to see if they're implemented. We'd have our own 'interface' system that would check a bloq's signature
(and anything else) to make sure it is compatible with the interface
I am getting an error when I try to get the call graph in this situation. I'm on the latest commit on main. Here is a MWE:
Here is the error I get: