Base implementation of user path extension [RFC]

[thilokru]

Current State

We are performing a lot of measurements, and it is often convenient to store them grouped by sample in a folder.
There is a hack to do so by changing the user's name:

old_user = qkit.cfg['user']
qkit.cfg['user'] = old_user + r"\Sample\SubSample\MeasurementType\"

This works, but is cumbersome.

Implementation Possibilities

Per Measurement

When a measurement is started, the information could be pulled from the sample object. This, however is highly measurement specific and is not available at the point where the file name is generated (in hdf_DateTimeGenerator.py).

Global Configuration (With provided implementation)

Less nice, but simpler to implement and test. A new configuration option would be available, called path_extension (preliminary). If set to a non-empty string, then the path is extended in hdf_DateTimeGenerator.py.

Usage would look like this:

qkit.cfg['path_extension'] = r"Sample\SubSample\MeasurementType"

This allows the user to set the sample at the beginning of the notebook. This has two disadvantages:

• The user may forget to update this setting (but this is the case anyway)
• The information may differ from what is set in the Sample object. This is a bit more annoying, but happens already anyway.

The provided implementation includes pytest tests to verify that the implementation is equivalent to the old behaviour if path_extension is not set.

Possible Extension: Natively Supported Hirarchy

If an array of strings were allowed, then

qkit.cfg['path_extension'] = ["Sample", "SubSample", "MeasurementType"]

colud become possible, removing problems with \ and escape sequences.

Possible Extension: Self-Resetting Configuration as a Safety Measure

qkit.cfg['path_extension'] could be reset after each measurement to enforce the user sets it before each measurement. This would relax the second disadvantage mentioned above.

Request for Comment

This is a change in the core module of qkit, which is why I'd like to ask for comments. I see the following questions:

1. Something like this is done in a hacky way already. Should we standardize this?
2. Should we enforce the hacky way is no longer possible?
3. Is an implementation in this way ok?
4. Is the name path_extension clear enough?
5. What form of documentation is needed?