Deprecate QuantumInstance and Opflow#9176
Conversation
|
Thank you for opening a new pull request. Before your PR can be merged it will first need to pass continuous integration tests and be reviewed. Sometimes the review process can be slow, so please be patient. While you're waiting, please feel free to review other open PRs. While only a subset of people are authorized to approve pull requests for merging, everyone is encouraged to review open pull requests. Doing reviews helps reduce the burden on the core team and helps make the project's code better for everyone. One or more of the the following people are requested to review this:
|
bc7287d to
4a07822
Compare
Pull Request Test Coverage Report for Build 4736561651
💛 - Coveralls |
jakelishman
left a comment
There was a problem hiding this comment.
I'll be glad to see the back of QuantumInstance in particular. This is going to be one of the larger deprecations and transitions we have to navigate our users through, and I don't think we're offering enough support in this PR.
Some questions about how this deprecation is being done:
- There are a lot of
opflowimports remaining inqiskit.algorithms. What is happening to these? They should be migrated before the deprecation. - There are a lot of
QuantumInstance-related methods and properties inalgorithms. What is happening to these? Should these be part of the same deprecation? - Removing
opflowandQuantumInstanceis a massive change to the algorithms/applications interface. What transition guides do we have in place to manage this change? We should be promoting these heavily before any deprecations actually land in release Terra.
This is going to be a massive inconvenience for users, and we really need to make sure we're probably preparing them for the transition. All the warnings we're emitting need to be clear about what the alternative is, and give them links to how they can transition their code. We need those transition guides in place and being widely publicised, along with the reasons why, before we drop any warning messages on users.
General comments on the implementation here:
- putting "Deprecated" into a docstring isn't the proper way to show deprecations - that's the
.. deprecated::directive. - documentation needs updating to show the new paths, not just to
warnings.filterwarningsthe messages away - It's not generally good to use
catch_warningsin library code; it's slow, clunky, and often hides true warnings. Instead, thestacklevelarguments should be set correctly such that Qiskit library code should be blamed for the warning where appropriate, which preventsDeprecationWarningfrom being shown to users with default filters. - in all
deprecate_functioncalls, we should be pointing users to what they should be using instead, preferably via a complete migration guide. - the testing of the warnings here is not sufficient. We cannot suppress warnings generated by
algorithmsand other Terra places because ofopflowuse - we need to know about them, and fix them before the warnings are emitted. If we can't do that, how are we expecting users to do it? If there are undeprecated public entry points inalgorithmsand elsewhere that should warn on certain inputs, then they should have tests asserting that they do.
Other places to consider:
qiskit.utils.backend_utilsfeels veryQuantumInstance-y. Can we deprecate that now?qiskit.utils.mitigation.fittersrefers toQuantumInstace. Do we need to do something about this?
6b39927 to
fb44b40
Compare
c33ea07 to
e1c28d2
Compare
Restore opflow test case Restore estimator test Restore unchanged tests
woodsp-ibm
left a comment
There was a problem hiding this comment.
Seems we are finally there with this. It all looks good to me with the code and the API ref docs from it. Thanks @ElePT for picking thus up and seeing it through to the end, and thanks to @manoelmarques for the initial effort this was based on.
| ) | ||
| def make_immutable(obj): | ||
| """Delete the __setattr__ property to make the object mostly immutable.""" | ||
| r"""Deprecate\: Delete the __setattr__ property to make the object mostly immutable.""" |
There was a problem hiding this comment.
| r"""Deprecate\: Delete the __setattr__ property to make the object mostly immutable.""" | |
| r"""Deprecated\: Delete the __setattr__ property to make the object mostly immutable.""" |
There was a problem hiding this comment.
This method is not used outside or operator globals. It could have been private rather than seeming to be public. Either way the intent was that this function was more an internal function in opflow and it is not linked in the API ref. so the spelling without a d at the end will only ever be seen if you look at the source code - hence it could just as well be left as it.
|
Oh man can't believe it lasted this long! I too am glad to see the quantum instance behind us, and glad the quantum_info is now far enough along that we don't need duplicate ops and states for the algos. Amazing work on the migration guides! Crazy comprehensive. |
Summary
Details and comments
These classes/functions outside the opflow module still use opflow as method argument or internal code:
qiskit.synthesis.evolution.QDrift-> removed in this PR