str(GridQubit) too similar to str(tuple)

[mpharrigan]

Was just waylaid in debugging an issue because I thought I was dealing with two-tuples but it was actually a GridQubit. Their str representation is indistinguishable. I suggest adding a subtle hint that it's different.

The closest analogy I can think of is the difference between a python list and a numpy array

In[3]: l = [1, 2, 3]
In[4]: print(l)
[1, 2, 3]
In[5]: print(np.asarray(l))
[1 2 3]

[Strilanc]

This can be a bit of a nasty change to make, because it affects circuit diagrams.

We may want to separate the circuit representation of a qubit from its __str__.

[mpharrigan]

Yes, I find it surprising that the circuit representation relies on __str__. Everything else (i.e. gates) uses _circuit_diagram_info_

[dabacon]

One suggestion is q(1,2), which we could then LineQubit could be q(1) and NamedQubit could be q(foo). I think this is better than modifying just GridQubit because it is more universal.

[Strilanc]

Agree that q(row, col) is superior to row_col for our purposes because it can be consistent across qubit types.

[dstrain115]

Are we okay with doing that change if it breaks circuit diagrams and other things that depend on str representations?

[mpharrigan]

My initial preference is for keeping circuit diagrams the same. Context is clear in circuit diagram anyways.

Changing the str for qubits might break things as well? I've seen str(q) used as measurement keys. This probably would still work in the majority of cases where str(q) is used to retrieve measurements by key, but wouldn't if people were re-constructing strings or re-processing saved results

[cduck]

Qubits could have their own version of _circuit_diagram_info_ so the diagram isn't dependent on the string representation. This would allow a more clear str(q) without changing diagrams.

[dstrain115]

Resurfacing this as a discuss item, so we can figure out if this is really needed or not.

[maffoo]

I like @dabacon's suggestion about q(1, 2) with support for line qubits and named qubits as well. Could even have a cirq.q function that can be called in each of these ways and is overloaded to produce the appropriate qubit type.

[tanujkhattar]

From cirq sync:

We should do this!

[dabacon]

cirq.q added in #5181