question-mark
Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Should we deprecate Circuit.device?

See original GitHub issue

Currently, each and every cirq.Circuit has a device attribute which defaults to UnconstrainedDevice. I think the original idea was that validation of device constraints would happen during circuit construction.

  1. This strikes me as strange. It makes more sense to me to have a device validate a circuit.
  2. Separating validation from circuit construction would permit more useful validation functionality. For example: instead of erroring out at the first bad gate, you could return a list of all the problems found and/or suggestions on how to fix problems identified
  3. In my experience, no one uses cirq.Circuit.device. You could argue that this attribute is a good marker for how the circuit has been compiled (i.e. what it’s targeted at) but the provided compilers / circuit transformers don’t set this property on the resultant circuit.

xref #3244

Issue Analytics

  • State:closed
  • Created 3 years ago
  • Comments:7 (3 by maintainers)

github_iconTop GitHub Comments

1reaction
dabaconcommented, Nov 16, 2020

It was originally designed to do validation, i.e. to enforce that your circuit could run on the given device.

I think I’m the one who advocated the mistaken pattern of using it during circuit construction. There was a nice use case where you could use it to gracefully handle the “not parallel ops” in the old Bristlecone architecture.

I think it should be deprecated as well. (I suspect there is a major problem in that we didn’t separate construction from use in the Circuit object and so it might be natural to have specific constructor patterns for circuits, they shouldn’t live in circuit.)

1reaction
mpharrigancommented, Sep 16, 2020

The problems with keeping it are

  1. since it’s neglected, new features sometimes introduce bugs when the developer forgets to think about this parameter (think: serializing circuits, circuit transformers)
  2. it’s unclear how circuit transformers should deal with the device attribute. Forward it? set it to something indicating the target of the transformation? Set it to UnconstrainedDevice?
Read more comments on GitHub >

github_iconTop Results From Across the Web

How long to wait before deleting a deprecated method? [closed]
Give them a clear date after which the method will be removed. (Ideally, don't actually remove it immediately on this date: wait until...
Read more >
If something is deprecated, can I still use it? [duplicate]
It means that it is bad practice to use it. It can still be used, but eventually it will not work with other...
Read more >
Deprecation - Wikipedia
Typically, deprecated materials are not completely removed to ensure legacy compatibility or back up practice in case new methods are not functional in...
Read more >
Resiliency: two alternatives for fault tolerance to deprecated ...
One idea is to run an agent like Splunk or AppDynamics like a side application and push the data to their respective logging...
Read more >
How and When to Deprecate APIs - Oracle Help Center
Deprecation is a reasonable choice in all these cases because it preserves "backward compatibility" while encouraging developers to change to the new API....
Read more >

github_iconTop Related Medium Post

No results found

github_iconTop Related StackOverflow Question

No results found

github_iconTroubleshoot Live Code

Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start Free

github_iconTop Related Reddit Thread

No results found

github_iconTop Related Hackernoon Post

No results found

github_iconTop Related Tweet

No results found

github_iconTop Related Dev.to Post

No results found

github_iconTop Related Hashnode Post

No results found