Closed thierry-martinez closed 6 months ago
Do we still want to support Python <3.10, or may we bump version constraint to allow match
construct?
Do we still want to support Python <3.10, or may we bump version constraint to allow
match
construct?
Good point, we might ditch 3.8 soon-ish but not sure yet about 3.9. Are there significant differences? if we can work around with a few lines of additional code, my personal opinion is it's good to keep supporting 3.9. What's your thoughts?
Are there significant differences? if we can work around with a few lines of additional code, my personal opinion is it's good to keep supporting 3.9. What's your thoughts?
Python 3.10 introduced match
-blocks, allowing branching code to be written more elegantly by pattern-matching instead of if-elif-else
chains. I rewrote in d7f7683 the few match
-blocks I introduced into if-elif-else
chains to be compatible with Python <3.10.
Python 3.9 allowed list and tuple types to be written as list[...]
and tuple[...]
instead of typing.List[...]
and typing.Tuple[...]
. I rewrote the types in 386f718 to be compatible with Python <3.9.
I think that when we will be ready to move to Python 3.10, match
-blocks will allow many code places to be written in a more readable way, but there is no urgency to do so.
Are there significant differences? if we can work around with a few lines of additional code, my personal opinion is it's good to keep supporting 3.9. What's your thoughts?
Python 3.10 introduced
match
-blocks, allowing branching code to be written more elegantly by pattern-matching instead ofif-elif-else
chains. I rewrote in d7f7683 the fewmatch
-blocks I introduced intoif-elif-else
chains to be compatible with Python <3.10.Python 3.9 allowed list and tuple types to be written as
list[...]
andtuple[...]
instead oftyping.List[...]
andtyping.Tuple[...]
. I rewrote the types in 386f718 to be compatible with Python <3.9.I think that when we will be ready to move to Python 3.10,
match
-blocks will allow many code places to be written in a more readable way, but there is no urgency to do so.
Thanks, that seems pretty good, let me think a bit. @masa10-f: let's discuss this next week.
Thanks! Merged.
This pull-request introduces a
pauli
module for symbolic Pauli calculations, which are used instatevec
instead of direct matrix computation. Thetest_pauli
module checks that the computations are the same as before, modulo a bug fix:CLIFFORD[CLIFFORD_CONJ[vop]]
was used instead ofCLIFFORD[vop].conj().T
, despite the two are only equal modulo phase in the general case (see the comment inpauli.py
). The new implementation allows the angle and the plane to be computed separately from the state vector back-end, which will be useful for future client/server computations and to share the code with other back-ends.