Suggestions for a proper instrument naming convention

[kel85uk]

Dear all,

Within the Quantify project, we use QCoDeS rather heavily. The recent release v0.34.x has broken a module within the project. In particular, we have an Edge submodule (the purpose of which is to contain connectivity information between a pair of qubits, which itself is a QCoDeS Instrument) which followed a naming convention of f"{parent_qubit}-{child_qubit}". My question to the community and to the devs in particular is what would be a suggested naming convention to stick to for the new update? Note that replacing the - with a _ might not work since we cannot assume that parent_qubit has no _ and we need to be able to identify the two qubits just from the name itself.

Many thanks in advance.

[astafan8]

@kel85uk hi, sorry for a late response.

It is difficult to suggest a new naming convention because it really should work for the use case you have in mind and implemented that object. A quick suggestion would be to use a double underscore to separate the parent and the child qubits, so parent__child. would that work?

Alternative direction to look at is - perhaps the connectivity information about the qubits should not be stored in a name of an instrument/submodule/channel? again, to exercise this direction i'd need to have more context to help you, and I also understand that this design decision may not be something that you'd want to adjust.

does this help?

[astafan8]

alright, you're most welcome @ereehuis !

[jenshnielsen]

@ereehuis Going forward would you be interested in validating a beta/rc release a week or so before the real release? Could be just running your test suite with Qcodes installed using the --pre flag to catch these things earlier? I have been doing a rather larger refactor (with backwards compatibility) but I would like to get it tested before release

[ereehuis]

That works for me, yes! So that is then by pulling and installing from the git repo? Where does the --pre come into play

[jenshnielsen]

So testing from master would also be very welcome! I was thinking to do a release which is marked as beta or release candicate and upload that to pypi. That way you can install it directly with pip like normally but only if you pass the --pre flag to pip otherwise pip will simply ignore it.

[ereehuis]

Gotcha. pip --pre route is simpler

Did a quick test, via pip install -e . I was able to install from code straight so that is manageable for me too

$ pip show qcodes
Name: qcodes
Version: 0.35.0.dev277+master.gb02efc674