Remove use of .device in contrib.
#4821
Merged
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
MichaelBroughton
requested review from
cduck,
vtomole and
a team
as code owners
MichaelBroughton
changed the title
.device in contrib.
95-martin-orion
added
the
BREAKING CHANGE
95-martin-orion
approved these changes
Jan 12, 2022
There was a problem hiding this comment.
You may want to hunt down the author of acquaintance to confirm this.
Otherwise, no complaints from me on this - for a long time I thought we didn't even test contrib, let alone make guarantees about stability, so I'm not too worried about deprecation-marking it.
|
cc: @bryano |
dstrain115
approved these changes
Jan 13, 2022
…n/Cirq into device_deprecate_contrib
MichaelBroughton
added
the
automerge
CirqBot
added
the
front_of_queue_automerge
CirqBot
removed
automerge
MichaelBroughton
added a commit
to MichaelBroughton/Cirq
that referenced
this pull request
Jan 22, 2022
Another sub-component for quantumlib#4744 . This removes the use of `circuit.device` from all contrib modules. BREAKING_CHANGE=removing the `device` property from the `SwapNetwork` class. It also removes some type checking done by the code (all logic in the bulk still works), which makes it more forgiving. With the amount of meaningful maintenance contrib has had (not much), I'm not a huge fan of going through a deprecation process for these mild behavior widenings with no API changes. Are others alright with this ?
rht
pushed a commit
to rht/Cirq
that referenced
this pull request
May 1, 2023
Another sub-component for quantumlib#4744 . This removes the use of `circuit.device` from all contrib modules. BREAKING_CHANGE=removing the `device` property from the `SwapNetwork` class. It also removes some type checking done by the code (all logic in the bulk still works), which makes it more forgiving. With the amount of meaningful maintenance contrib has had (not much), I'm not a huge fan of going through a deprecation process for these mild behavior widenings with no API changes. Are others alright with this ?
harry-phasecraft
pushed a commit
to PhaseCraft/Cirq
that referenced
this pull request
Oct 31, 2024
Another sub-component for quantumlib#4744 . This removes the use of `circuit.device` from all contrib modules. BREAKING_CHANGE=removing the `device` property from the `SwapNetwork` class. It also removes some type checking done by the code (all logic in the bulk still works), which makes it more forgiving. With the amount of meaningful maintenance contrib has had (not much), I'm not a huge fan of going through a deprecation process for these mild behavior widenings with no API changes. Are others alright with this ?
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.
Another sub-component for #4744 . This removes the use of
circuit.devicefrom all contrib modules.BREAKING_CHANGE=removing the
deviceproperty from theSwapNetworkclass.It also removes some type checking done by the code (all logic in the bulk still works), which makes it more forgiving.
With the amount of meaningful maintenance contrib has had (not much), I'm not a huge fan of going through a deprecation process for these mild behavior widenings with no API changes. Are others alright with this ?