Follow through with PendingDeprecationWarnings #8023
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This commit promotes several pending deprecation warnings from earlier releases to full deprecation warnings making them user facing. Specifically, the qiskit.circuits.qpy_serialization module, the legacy scheduling paths, and the qobj support in basic aer are now deprecated as they have been pending deprecation for at least 1 release. This starts the timer on pending removal per the qiskit deprecation policy [1] so we can remove this functionality in >= 3 months and > 1 release. Meaning all of these are eligble for removal in qiskit-terra 0.23.0 (assuming that is at least 3 months after 0.21.0). [1] https://qiskit.org/documentation/contributing_to_qiskit.html#deprecation-policy
|
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:
|
Pull Request Test Coverage Report for Build 2457070427
💛 - Coveralls |
jakelishman
reviewed
May 5, 2022
Co-authored-by: Naoki Kanazawa <nkanazawa1989@gmail.com>
|
@mtreinish The docstring of |
ajavadia
reviewed
Jun 9, 2022
| "This class will be deprecated in a future release and subsequently " | ||
| "removed after that.", | ||
| PendingDeprecationWarning, | ||
| "This class is deprecated and will be removed in a future release", |
There was a problem hiding this comment.
Can i request that we postpone this deprecation until a future release while we build more confidence that the PadDynamicalDecoupling is the way to go (for other kinds of DD)
There was a problem hiding this comment.
Sure, I'll remove the deprecation of this and the matching scheduling passes and we can revisit for 0.22
There was a problem hiding this comment.
@ajavadia is this ready to be deprecated or do we want to keep it still? 🙂
Cryoris
reviewed
Oct 26, 2022
| def __getattr__(name): | ||
| if name in deprecated_names: | ||
| warnings.warn( | ||
| "The qiskit.circuit.qpy_serialization module is deprecated and has been supersceded " |
There was a problem hiding this comment.
😉
Suggested change
| "The qiskit.circuit.qpy_serialization module is deprecated and has been supersceded " | |
| "The qiskit.circuit.qpy_serialization module is deprecated and has been superseded " |
| "This class will be deprecated in a future release and subsequently " | ||
| "removed after that.", | ||
| PendingDeprecationWarning, | ||
| "This class is deprecated and will be removed in a future release", |
There was a problem hiding this comment.
@ajavadia is this ready to be deprecated or do we want to keep it still? 🙂
| - | | ||
| The :class:`~.ALAPSchedule` pass has been deprecated and will be removed | ||
| in a future release. Instead the :class:`~.ALAPScheduleAnalysis` pass should | ||
| be used in conjunction with a padding pass such as :class:`~PadDelay` or |
There was a problem hiding this comment.
Suggested change
| be used in conjunction with a padding pass such as :class:`~PadDelay` or | |
| be used in conjunction with a padding pass such as :class:`~.PadDelay` or |
|
This is super stale at this point so I'm going to close this, we can revisit this in a new PR. |
mtreinish
added a commit
to mtreinish/qiskit-core
that referenced
this pull request
Nov 2, 2023
In Qiskit#10754 3 legacy scheduling passes were accidently deleted. These passes were incorrectly identified as deprecated, however they were never marked as deprecating just pending future deprecation. They were intended to be be promoted from a pending deprecation to a full deprecation in Qiskit#8023 but we never took that step because there were objections at the time as they still served a purpose. Qiskit#10754 likely missed this as the only indication in the deprecation decorator was a kwarg that said `pending=True`, and this was the only indication that these passes weren't actually deprecated yet. This commit restores these passes on the 0.45.0 branch in the interest of unblocking the 0.45.0 release ASAP. We can handle forward porting this PR to main as needed after the 0.45.0 release is tagged.
mtreinish
added a commit
to mtreinish/qiskit-core
that referenced
this pull request
Nov 2, 2023
In Qiskit#10754 3 legacy scheduling passes were accidently deleted. These passes were incorrectly identified as deprecated, however they were never marked as deprecating just pending future deprecation. They were intended to be be promoted from a pending deprecation to a full deprecation in Qiskit#8023 but we never took that step because there were objections at the time as they still served a purpose. Qiskit#10754 likely missed this as the only indication in the deprecation decorator was a kwarg that said `pending=True`, and this was the only indication that these passes weren't actually deprecated yet. This commit restores these passes on the 0.45.0 branch in the interest of unblocking the 0.45.0 release ASAP. We can handle forward porting this PR to main as needed after the 0.45.0 release is tagged.
github-merge-queue bot
pushed a commit
that referenced
this pull request
Nov 3, 2023
In #10754 3 legacy scheduling passes were accidently deleted. These passes were incorrectly identified as deprecated, however they were never marked as deprecating just pending future deprecation. They were intended to be be promoted from a pending deprecation to a full deprecation in #8023 but we never took that step because there were objections at the time as they still served a purpose. #10754 likely missed this as the only indication in the deprecation decorator was a kwarg that said `pending=True`, and this was the only indication that these passes weren't actually deprecated yet. This commit restores these passes on the 0.45.0 branch in the interest of unblocking the 0.45.0 release ASAP. We can handle forward porting this PR to main as needed after the 0.45.0 release is tagged.
mergify bot
pushed a commit
that referenced
this pull request
Nov 3, 2023
In #10754 3 legacy scheduling passes were accidently deleted. These passes were incorrectly identified as deprecated, however they were never marked as deprecating just pending future deprecation. They were intended to be be promoted from a pending deprecation to a full deprecation in #8023 but we never took that step because there were objections at the time as they still served a purpose. #10754 likely missed this as the only indication in the deprecation decorator was a kwarg that said `pending=True`, and this was the only indication that these passes weren't actually deprecated yet. This commit restores these passes on the 0.45.0 branch in the interest of unblocking the 0.45.0 release ASAP. We can handle forward porting this PR to main as needed after the 0.45.0 release is tagged. (cherry picked from commit aa272e9)
github-merge-queue bot
pushed a commit
that referenced
this pull request
Nov 3, 2023
In #10754 3 legacy scheduling passes were accidently deleted. These passes were incorrectly identified as deprecated, however they were never marked as deprecating just pending future deprecation. They were intended to be be promoted from a pending deprecation to a full deprecation in #8023 but we never took that step because there were objections at the time as they still served a purpose. #10754 likely missed this as the only indication in the deprecation decorator was a kwarg that said `pending=True`, and this was the only indication that these passes weren't actually deprecated yet. This commit restores these passes on the 0.45.0 branch in the interest of unblocking the 0.45.0 release ASAP. We can handle forward porting this PR to main as needed after the 0.45.0 release is tagged. (cherry picked from commit aa272e9) Co-authored-by: Matthew Treinish <mtreinish@kortar.org>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
This commit promotes several pending deprecation warnings from earlier
releases to full deprecation warnings making them user facing.
Specifically, the qiskit.circuits.qpy_serialization module, the legacy
scheduling paths, and the qobj support in basic aer are now deprecated
as they have been pending deprecation for at least 1 release. This
starts the timer on pending removal per the qiskit deprecation
policy [1] so we can remove this functionality in >= 3 months and > 1
release. Meaning all of these are eligble for removal in qiskit-terra
0.23.0 (assuming that is at least 3 months after 0.21.0).
Details and comments
[1] https://qiskit.org/documentation/contributing_to_qiskit.html#deprecation-policy