`_Pauli{X,Y,Z}` maybe shouldn't be private

[mpharrigan]

Unlike every other gate, with cirq.X, cirq.Y, and cirq.Z, it's very easy to end up with an instance of a class that is not importable from top-level-cirq

x1 = cirq.X
x2 = cirq.X**0.99
type(x1)
Out[6]: cirq.ops.pauli_gates._PauliX
type(x2)
Out[7]: cirq.ops.common_gates.XPowGate

consider renaming to PauliX and exposing as cirq.PauliX

[mpharrigan]

Actually, this happens with a lot of singletons and is probably by design. Running into this when trying to automate testing for #1880

[dabacon]

Do we know this is the right pattern? We don't use singletons anywhere else and this is a pattern that may confuse a lot of people.

[mpharrigan]

There's a couple other places:

code to find these

import inspect
import cirq

def _get_all_public_things():
    for cls_name, cls_cls in inspect.getmembers(cirq):
        if inspect.isfunction(cls_cls) or inspect.ismodule(cls_cls):
            continue

        if not inspect.isclass(cls_cls):
            # singletons, for instance
            cls_cls = cls_cls.__class__

        yield cls_name, cls_cls


for cls_name, cls_cls in _get_all_public_things():
    if cls_cls.__name__.startswith('_'):
        print(f'{cls_name:20s} {cls_cls.__name__:20s}')

NO_NOISE             _NoNoiseModel       
OP_TREE              _Union              
ParamResolverOrSimilarType _Union              
PauliSumLike         _Union              
QubitOrderOrList     _Union              
Sweepable            _Union              
UnconstrainedDevice  _UnconstrainedDeviceType
UnitSweep            _Unit               
X                    _PauliX             
Y                    _PauliY             
Z                    _PauliZ         

[Strilanc]

I would omit the _Union types from consideration, since they are just shorthands for type annotations.

I am not opposed to making the singleton value types public. They pollute the autocomplete namespace with strings that are not useful to users, but on the otherhand it makes sense that if an instance is public then its type should also be public.

[mpharrigan]

For the purposes of #1880 automated testing, it no longer matters to me.

The _Union types are not ours, but shows that even the python-powers-that-be sometimes gives you an instantiation of a private class

[mpharrigan]

Here's all the singletons, for reference

CCNOT                CCXPowGate          
CCX                  CCXPowGate          
CCZ                  CCZPowGate          
CNOT                 CNotPowGate         
CONTROL_TAG          ndarray             
CSWAP                CSwapGate           
CX                   CNotPowGate         
CZ                   CZPowGate           
FREDKIN              CSwapGate           
H                    HPowGate            
I                    IdentityGate        
ISWAP                ISwapPowGate        
NO_NOISE             _NoNoiseModel       
OP_TREE              _Union              
PAULI_BASIS          dict                
ParamResolverOrSimilarType _Union              
PauliSumLike         _Union              
QubitOrderOrList     _Union              
S                    ZPowGate            
SWAP                 SwapPowGate         
Sweepable            _Union              
T                    ZPowGate            
TOFFOLI              CCXPowGate          
TParamVal            _Union              
UnconstrainedDevice  _UnconstrainedDeviceType
UnitSweep            _Unit               
X                    _PauliX             
XX                   XXPowGate           
Y                    _PauliY             
YY                   YYPowGate           
Z                    _PauliZ             
ZZ                   ZZPowGate           
reset                ResetChannel   

[dabacon]

I don't mind many of these Singletons in this long list, though I do think that they should follow style guidelines and be CAPS (ignore union types as Craig said). UnconstrainedDevice, reset seem to violate this.

[dabacon]

The thing about Pauli is that I don't see why we shouldn't just have the XPowGate, and, in the case where the exponent is such that we have and I or and X the methods that Pauli supports are used? In looking over pauli_string I don't see a great reason for this. We could also make this a proper interface, and this would allow code to still spot that the object is potentially a Pauli by class and then by calling a is_pauli method.

[mpharrigan]

I do think that they should follow style guidelines and be CAPS

xref #2011

[mpharrigan]

I'd generally push back against any further consolidation into them being gate-like. I'm still not fully convinced that there shouldn't be two separate things: X-the-gate and X-the-operator. It's pretty rare to have a case where you want to take one thing and use it both as an operator (Hermitian) and a gate (unitary). In fact, most of the time when you have an X-the-operator, you convert to an associated gate by exp[i t X-the-operator].

The only commonality is the matrix representation, so you'd want to call cirq.unitary(X-the-gate) or cirq.unitary(X-the-operator) and get the same answer; but this also gets confusing in the latter case because you're not requesting a unitary matrix. You really need a Hermitian matrix.