Deprecate the condition attribute and related functionality#13223
Deprecate the condition attribute and related functionality#13223ElePT merged 13 commits intoQiskit:mainfrom
Conversation
This commit deprecates the Instruction.condition and c_if() method for removal in 2.0. This functionality has been superseded by the more sophisiticated `IfElseOp` for some time now. Removing the condition property will simplify the Qiskit data model as it is implemented in a kind of ad-hoc manner that adds additional overhead to manually check it in many places. For the unittest modifications the deprecation warning for the .condtion getter is suppressed for the entire suite because this gets triggered internally by the transpiler and a lot of other places, including from rust code as until it is removed we need to use it to check that piece of the data model. Fixes Qiskit#9556
|
One or more of the following people are relevant to this code:
|
Pull Request Test Coverage Report for Build 11599100254Warning: This coverage report may be inaccurate.This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.
Details
💛 - Coveralls |
Co-authored-by: Elena Peña Tapia <57907331+ElePT@users.noreply.github.com>
ElePT
left a comment
There was a problem hiding this comment.
LGTM! I just found a couple of deprecation warning assertions that I think would be good to clarify (maybe adding a comment explaining how they relate to this deprecation like you did in other cases).
| with self.assertWarns(DeprecationWarning): | ||
| self.assertTrue(Operator(circuit).equiv(Operator(result))) |
There was a problem hiding this comment.
Where is the warning triggered here?
There was a problem hiding this comment.
Operator(circuit) runs circuit.to_instruction() which checks for condition iirc.
| with self.assertWarns(DeprecationWarning): | ||
| new_qc = ResetAfterMeasureSimplification()(qc) |
There was a problem hiding this comment.
Do you think this class raising a deprecation warning is a desired outcome (I'm not sure why it's raised)? Maybe the stack level of the warning isn't correct?
There was a problem hiding this comment.
The testing harness will trigger if the warning is raised at any stack level even if it's not user code. This is to let us catch internal usage of deprecated functionality in our dependencies. In this case the ResetAfterMeasureSimplification pass only works with c_if and condition. so the warning is coming from inside the pass.
This does raise a good question about what we want to do with that pass, we probably should convert it to an if statement internally. I don't remember what I was thinking when I opened this 2 weeks ago, probably that I would do it in a followup PR. But it would be better if I do it here instead.
There was a problem hiding this comment.
When I went to do this I remember why I didn't change it. I decided at the time that leaving the pass using c_if for 1.x made the most sense as using an IfElseOp instead could have been viewed as a potential change in behavior and wanted to save that for 2.0.
There was a problem hiding this comment.
I agree with not changing the behavior yet. I brought this up thinking about downstream packages and how they sometimes get "flooded" by our deprecation warnings even if they aren't actionable. But I guess it's on them to set the stack level they want to see in their tests.
This commit fixes some places in the code where we were using the deprecated functionality where it needed a path to persist the behavior or where the deprecation warning became a performance bottleneck. The code is updated accordingly and to catch issues like this in the future the warning filters are adjusted to be more selective.
| with self.assertWarns(DeprecationWarning): | ||
| new_qc = ResetAfterMeasureSimplification()(qc) |
There was a problem hiding this comment.
I agree with not changing the behavior yet. I brought this up thinking about downstream packages and how they sometimes get "flooded" by our deprecation warnings even if they aren't actionable. But I guess it's on them to set the stack level they want to see in their tests.
| qc = QuantumCircuit(2, 2) | ||
| qc.h(0) | ||
| qc.x(0).c_if(0, 1) | ||
| qc.z(1.c_if(1, 0) | ||
| qc.measure(0, 0) | ||
| qc.measure(1, 1) | ||
|
|
||
| can be rewritten as:: | ||
|
|
||
| qc = QuantumCircuit(2, 2) | ||
| qc.h(0) | ||
| with expected.if_test((expected.clbits[0], True)): | ||
| qc.x(0) | ||
| with expected.if_test((expected.clbits[1], False)): | ||
| qc.z(1) | ||
| qc.measure(0, 0) | ||
| qc.measure(1, 1) |
There was a problem hiding this comment.
I just started addressing this deprecation warning and noticed some issues here. I think it should be qc.z(1) (missing parenthesis). Also, I think expected should be qc?
Summary
This commit deprecates the Instruction.condition and c_if() method for removal in 2.0. This functionality has been superseded by the more sophisiticated
IfElseOpfor some time now. Removing the condition property will simplify the Qiskit data model as it is implemented in a kind of ad-hoc manner that adds additional overhead to manually check it in many places.For the unittest modifications the deprecation warning for the .condtion getter is suppressed for the entire suite because this gets triggered internally by the transpiler and a lot of other places, including from rust code as until it is removed we need to use it to check that piece of the data model.
Details and comments
Fixes #9556