Skip to content

SerializableGateSet deprecation #5573

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

Conversation

verult
Copy link
Collaborator

@verult verult commented Jun 22, 2022

  • Deprecate global SerializableGateSets
  • Deprecate GOOGLE_GATESETS. This is not exposed in cirq_google/init.py; it is only used in engine_program.py for selecting the deserializer using the Program.language.gate_set proto field. Removing other gatesets from consideration here is premature since global gatesets have not been removed. This code should move to CircuitSerializer completely before 1.0.
  • Deprecate the SerializableGateSet class. A new class wrapper is introduced to bypass the behavior that deprecation warnings thrown while loading global gatesets at the module level fail unit tests.

@dstrain115 @MichaelBroughton

@verult verult requested review from wcourtney, a team, vtomole and cduck as code owners June 22, 2022 17:49
@CirqBot CirqBot added the size: XL lines changed >1000 label Jun 22, 2022
@@ -164,7 +164,10 @@
_compat.deprecate_attributes(
__name__,
{
'Bristlecone': ('v0.15', 'Bristlecone will no longer be supported.'),
'Foxtail': ('v0.15', 'Foxtail will no longer be supported.'),
'XMON': ('v0.16', 'SerializableGateSet will no longer be supported.'),
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we point them to CircuitSerializer? Or say that gatesets are no longer required for Engine, or something?

engine_validator.validate_gate_set(
[circuit] * 10, [{}] * 10, 1000, cg.FSIM_GATESET, max_size=100000
[circuit] * 5, [{}] * 5, 1000, cg.FSIM_GATESET, max_size=100000
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it possible to change this reference to CircuitSerializer? Same with below.

Copy link
Collaborator Author

@verult verult Jun 22, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We can, but to help get deprecations out the door, I deferred caller changes to after the 0.15 release wherever I can. We'll have to cross this bridge again when we remove SerializableGateSet.

Will keep a note of this for SerializableGateSet removal.

cig.SQRT_ISWAP_GATESET.serialize(converted_circuit)
cig.SQRT_ISWAP_GATESET.serialize(converted_circuit_iswap)
cig.SQRT_ISWAP_GATESET.serialize(converted_circuit_iswap_inv)
with cirq.testing.assert_deprecated('SerializableGateSet', deadline='v0.16', count=None):
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should consider validating this with a compilation target gate set instead?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same as the other case - I'll keep a note of this for SerializableGateSet removal as well.

@@ -24,10 +24,11 @@
_GateOrFrozenCircuitTypes = Union[Type[cirq.Gate], Type[cirq.FrozenCircuit]]


class SerializableGateSet(serializer.Serializer):
"""A class for serializing and deserializing programs and operations.
class _SerializableGateSet(serializer.Serializer):
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we deprecate the functions in this class? If we deprecate the functions in the class, then any use will generate a warning, right? That way, instantiation won't generate a warning, but if it is used to serialize a class, it will generate a warning.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmmm yeah potentially. One concern is that there could be more call sites to the methods than the constructor since some code interacts with SerializableGateSet via the Serializer interface, leading to more tests that need to be updated. More work, but certainly less hacky.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tried deprecating the serialize() method and only got test failures in serializable_gate_set_test.py, so perhaps it's OK. On the other hand, I'll run into the same problem for deprecating serializers as well, and I can't tell for sure whether test files for testing callers of class methods will fail.

Given that, my preference is to do the simplest thing and keep it the way it, since a lot of the code here will be removed very soon.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it would be preferable to at least deprecate the serialize() method. That way people get a message when they use the most common call site at least.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Chatted offline - the most common call site for users is via global gatesets, which have a separate deprecation warning in place to tell users about SerializableGateSet deprecation.

verult added 2 commits June 23, 2022 02:47
Deprecating the class directly will cause global gatesets such as SYC_GATESET to throw a deprecation warning during module loading. A shell class (containing class documentation) is created to avoid this.
@verult verult force-pushed the cg-device-refactor/well-known-gatesets-deprecation branch from b79bb1e to 0bb9a06 Compare June 23, 2022 02:49
@verult
Copy link
Collaborator Author

verult commented Jun 23, 2022

In the latest push: expanded on the fix message for deprecated global gatesets, and also added a sentence about the gateset no long being necessary in engine.

Copy link
Collaborator

@dstrain115 dstrain115 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Author commented that the _SerializableGateset path was already protected by a deprecation message via the deprecate_attributes() call.

@verult verult added the automerge Tells CirqBot to sync and merge this PR. (If it's running.) label Jun 23, 2022
@CirqBot CirqBot added the front_of_queue_automerge CirqBot uses this label to indicate (and remember) what's being merged next. label Jun 23, 2022
@CirqBot CirqBot merged commit abfc619 into quantumlib:master Jun 23, 2022
@CirqBot CirqBot removed automerge Tells CirqBot to sync and merge this PR. (If it's running.) front_of_queue_automerge CirqBot uses this label to indicate (and remember) what's being merged next. labels Jun 23, 2022
@verult verult mentioned this pull request Jul 7, 2022
40 tasks
rht pushed a commit to rht/Cirq that referenced this pull request May 1, 2023
* Deprecate global SerializableGateSets
* Deprecate `GOOGLE_GATESETS`. This is not exposed in cirq_google/__init__.py; it is only used in `engine_program.py` for selecting the deserializer using the Program.language.gate_set proto field. Removing other gatesets from consideration here is premature since global gatesets have not been removed. This code should move to CircuitSerializer completely before 1.0.
* Deprecate the `SerializableGateSet` class. A new class wrapper is introduced to bypass the behavior that deprecation warnings thrown while loading global gatesets at the module level fail unit tests.

@dstrain115 @MichaelBroughton
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
size: XL lines changed >1000
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants