-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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 qiskit.extensions
#11488
Remove qiskit.extensions
#11488
Conversation
One or more of the the following people are requested to review this:
|
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.
This largely looks sensible to me, thanks. The lint failures are all trivial unused imports, and I commented on the two docs problems.
# DiagonalGate (and a bunch of the qiskit.extensions gates) have non-deterministic | ||
# DiagonalGate (and some of the qiskit.circuit.library gates) have non-deterministic |
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.
lol, I'm betting I wrote that "a bunch"
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.
haha I proposed to tone it down since now it's only a few gates from the standard library (whereas before it was lot of the ones in extension) 😛
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.
Haha yeah, that's fine. I'm mostly laughing at my terminology - I think I'm the only one of us who talks like that, and almost certainly the only one who writes code like that.
Pull Request Test Coverage Report for Build 7556014030Warning: This coverage report may be inaccurate.We've detected an issue with your CI configuration that might affect the accuracy of this pull request's coverage report.
💛 - Coveralls |
Snapshot instruction has been removed
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.
Thanks for this - the release note is much more helpful now!
I guess the MPL test of "barrier-like objects" is no longer doing as much of its job (now it only tests real barriers), but I'm not beaten up about that - I'm not convinced that a barrier is the best drawing choice for an arbitrary "directive" anyway.
params: Sequence[complex] | str | int, | ||
params: Statevector | Sequence[complex] | str | int, |
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.
Sequence[complex]
is overspecified (my pet complaint that Sequence
is pretty much never correct as a type hint), but leaving aside .index
and .count
, Statevector
would actually have already been covered by a type-hint of numpy.typing.ArrayLike
, which is more appropriate.
That's not important, though, I just like complaining about Sequence
.
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.
But this would be nice to rework consistently in all type hints (though numpy.typing.ArrayLike
is a bit long 😛)
# DiagonalGate (and a bunch of the qiskit.extensions gates) have non-deterministic | ||
# DiagonalGate (and some of the qiskit.circuit.library gates) have non-deterministic |
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.
Haha yeah, that's fine. I'm mostly laughing at my terminology - I think I'm the only one of us who talks like that, and almost certainly the only one who writes code like that.
Actually, I'm removing this from the merge queue and placing "on hold" until the deprecations at least have a PR open, because it's not eligible for merge without them. It's ready to merge as soon as that's in place, though. |
Deprecation PR is coming up 🙂 |
Also on hold due to Qiskit/qiskit-aer#2023. |
Yeah, it's not great that our CI is configured in such a way that we didn't notice that Aer fails to import with this change in place. |
Removing |
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.
Thanks for getting this sorted!
This reverts commit 5dbe66d.
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.
Thanks for clearing up the test skips. I scanned through again, and it looks like it's all back in the state that I originally approved.
Summary
Remove the (sort of) deprecated
qiskit.extensions
module for Qiskit 1.0 and remove deprecated circuit methods (such asfredkin
). I'm not sure if the reno should be more detailed, here I'm referring to the 0.45 reno, but we could also repeat that information here.A separate PR will deprecate
qiskit.extensions
on the 0.46 branch.Details and comments
prepare_state
method should've been moved toquantumcircuit.py
in the deprecation PR but I overlooked it