-
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
Deprecate tuple-like access to CircuitInstruction
#12640
Deprecate tuple-like access to CircuitInstruction
#12640
Conversation
One or more of the following people are relevant to this code:
|
This has been the legacy path since `CircuitInstruction` was added in Qiskitgh-8093. It's more performant to use the attribute-access patterns, and with more of the internals moving to Rust and potentially needing more use of additional class methods and attributes, we need to start shifting people away from the old form.
29980c1
to
9a08838
Compare
Pull Request Test Coverage Report for Build 9617201737Details
💛 - Coveralls |
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.
LGTM, this is straightforward enough and it's good to have a deprecation warning pattern for Python from rust now.
// Stack level. Compared to Python-space calls to `warn`, this is unusually low | ||
// beacuse all our internal call structure is now Rust-space and invisible to Python. | ||
1, |
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 isn't great, but yeah there isn't really an alternative because the call stack isn't really accessible 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.
tbh, I think it might actually work out better from Rust space than it otherwise would, because this is only called by magic methods, which have weird callstacks already, since some of the "logical" parts of it are CPython internals already.
Setting stacklevel=1
here causes everything I could think of to get blamed on the actual triggering line in Python space.
I think, randomized tests is still using this deprecated behavior https://github.com/Qiskit/qiskit/actions/runs/9656096284/job/26633022278 |
This has been the legacy path since `CircuitInstruction` was added in Qiskitgh-8093. It's more performant to use the attribute-access patterns, and with more of the internals moving to Rust and potentially needing more use of additional class methods and attributes, we need to start shifting people away from the old form.
… (Qiskit#12663) * addapting to Qiskit#12640 * more instances
Summary
This has been the legacy path since
CircuitInstruction
was added in gh-8093. It's more performant to use the attribute-access patterns, and with more of the internals moving to Rust and potentially needing more use of additional class methods and attributes, we need to start shifting people away from the old form.Details and comments
Fix #12631.
The sister PR to Aer that fixes its remaining uses of this is Qiskit/qiskit-aer#2179.