Rename _channel_ to _kraus_
#4139
Conversation
|
Check out this pull request on See visual diffs & provide feedback on Jupyter Notebooks. Powered by ReviewNB |
There was a problem hiding this comment.
Do we consider _channel_ to be part of our API? I know the preceeding underscore means "private" in Python, but in Cirq (and IPython, numpy(?), maybe others) flanking underscores means magic method that 3rd party classes can implement.
I can certainly see a situation where someone has their own gate or channel that defines _channel_ and this would break them. Would it be worth the effort to go through a deprecation cycle? I don't think it would be too hard to fall back to _channel_ (and emit a warning) if it exists and _kraus_ doesn't.
cirq-core/cirq/protocols/channel.py
Outdated
| def _channel_(self) -> Union[Sequence[np.ndarray], NotImplementedType]: | ||
| r"""A list of matrices describing the quantum channel. | ||
| def _kraus_(self) -> Union[Sequence[np.ndarray], NotImplementedType]: | ||
| r"""A list of Kraus operators describing the quantum channel. |
| @@ -266,7 +266,7 @@ def err_str(buf_num_str): | |||
| return default | |||
| raise TypeError( | |||
| "object of type '{}' has no _apply_channel_, _apply_unitary_, " | |||
There was a problem hiding this comment.
Should we also rename _apply_channel_, or is that method more generally applicable to other channel representations?
There was a problem hiding this comment.
I think we should make sure that apply_channel protocol works with all channel representations. It's more user-friendly than having an apply* protocol for each representation and forcing the user to check which representation they have at their disposal.
|
PTAL |
Follow-up to quantumlib#4139 and quantumlib#4195. Fixes quantumlib#4138.
This renames magic methods
_channel_to_kraus_and_has_channel_to_has_kraus_. Follow-up renames the protocolscirq.channeltocirq.krausandcirq.has_channeltocirq.has_kraus.Context: #4138.