New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove code due to be removed in v0.28 #3281
Conversation
Codecov Report
@@ Coverage Diff @@
## master #3281 +/- ##
==========================================
- Coverage 99.70% 99.70% -0.01%
==========================================
Files 299 298 -1
Lines 26214 26142 -72
==========================================
- Hits 26136 26064 -72
Misses 78 78
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Co-authored-by: Matthew Silverman <matthews@xanadu.ai>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Two notes for consistency but otherwise lgtm!
- Two of the pending deprecations say "Will be removed in v0.28" - are we sure we'll get to them? Otherwise it will clash with the completed deprecations that say "Removed in v0.28". Not sure what I'm asking for here. Stories to track them? Optimistically change the language now? A calendar reminder to ensure it's updated pre-release? Nothing is also acceptable, just making sure it's pointed out.
- The newly completed deprecations have the first line saying "Still accessible in vX.Y", while the previously existing ones say "Deprecated in vX.Y". Can we make them the same? I'd prefer "Deprecated in".
For the grouping deprecation, let's make a separate PR for that @Jaybsoni . Since that will be a lot of deletions and clean up. I'm unsure whether we should actually remove Updated the language for "Completed deprecation cycles". |
This was originally added in #3182, but I only put the test in `test_tape.py`, so it was accidentally pruned in #3281 (anagram PR!) which isn't ideal. I'm putting it back in `test_queuing.py` where it truly belongs. I know this PR seems a bit insignificant, but I remember this bug coming up and I don't want it to resurface because of a lack of testing. Plus, the `finally` is much prettier than writing the cleanup code twice 😄 Not bothering with a changelog entry, but can add if we feel strongly about it
A variety of code is due to be removed for the v0.28 release. See the deprecations page for the full list.
The list is:
qml.tape.get_active_tape
: Useqml.QueuingManager.active_context()
qml.transforms.qcut.remap_tape_wires
: Useqml.map_wires
qml.tape.QuantumTape.inv()
: Useqml.tape.QuantumTape.adjoint()
qml.tape.stop_recording()
: Useqml.QueuingManager.stop_recording()
qml.tape.QuantumTape.stop_recording()
: Useqml.QueuingManager.stop_recording()
qml.QueuingContext
is nowqml.QueuingManager
QueuingManager.safe_update_info
andAnnotatedQueue.safe_update_info
: Use plainupdate_info