tetra-quark / deeplabcut Goto Github PK

Search repo for "CollectedData_" for example usages. There are basially two types that need refactoring, those that specify the parent folder of the CollectedData file and the ones that get it from the labeled-data folder for the iteration. The function should ideally be able to deal with both cases but might actually need two functions.

Type 1:

    Data = pd.read_hdf(
        os.path.join(
            cfg["project_path"],
            str(trainingsetfolder),
            "CollectedData_" + cfg["scorer"] + ".h5",
        )
    )

becomes:

    Data = pd.read_hdf(
        get_collected_data_file_path(cfg),
    )

Type 2:

    os.path.join(str(folder), "CollectedData_" + cfg["scorer"] + ".csv")

Is your feature request related to a problem? Please describe.

Currently the main project config and both pose config files are often accessed through a dictionary attribute in certain classes. They are usually simply called 'cfg' and thus it is difficult to know which config file is being used without looking at which keys are being accessed or having more knowledge of the context of the code. I believe improving this would add a lot to the clarity and maintainability of the DeepLabCut repository.

Describe the solution you'd like

I think it would be a lot cleaner to implement these config dict attributes as a dataclasses. The dataclass could remain an attribute of the class in which it is used.

Structuring the config like this could enable other classes such as Project or Model classes that can handle paths and creating, loading, updating files in a cleaner way. Could handle conversions and formatting that are done everytime the variable is loaded or accessed. Ex. store datetime easily converted to 'dd-mm-yyyy' is converted to 'JanYY'.

Pros:

• Clarify what kind of config file is being used
• Enable suggestions and auto-completion during development

Cons:

• key-value pairs are added in the running code and are not part of any config file, need to handle that.
• any backwards compatibility issues?

Need to think a bit more deeply about the structure and how it would work.

Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.

Additional context
Add any other context or screenshots about the feature request here.