Is your feature request related to a use case or problem? Please describe.
Currently when one introduces a new public class in the cirq namespace, they have to add either make it json serializable and provide test data or have to mark them as "not yet serializable" or "should not be serializable". With the modularization of the JSON testing these lists are going to get unwieldy, as for each module we'll have two lists that the objects should belong.
Describe the solution you'd like
Instead of maintaining lists of object names, instead we could use python decorators @cirq.exempt_from_json_serialization(reason='not_yet'), @cirq.exempt_from_json_serialization(reason='never').
What is the urgency from your perspective for this issue? Is it blocking important work?
P1 - I need this no later than the next release (end of quarter)
Is your feature request related to a use case or problem? Please describe.
Currently when one introduces a new public class in the cirq namespace, they have to add either make it json serializable and provide test data or have to mark them as "not yet serializable" or "should not be serializable". With the modularization of the JSON testing these lists are going to get unwieldy, as for each module we'll have two lists that the objects should belong.
Describe the solution you'd like
Instead of maintaining lists of object names, instead we could use python decorators
@cirq.exempt_from_json_serialization(reason='not_yet')
,@cirq.exempt_from_json_serialization(reason='never')
.What is the urgency from your perspective for this issue? Is it blocking important work?
P1 - I need this no later than the next release (end of quarter)