yeah its obsolete. This is an old branch that recently got synced with latest staging. It looks like the CR doesn't recognize the correct changes from staging. There should only be 1 file change ( conductivity sensors ).

We agreed to change back the enums into the static variation.
Why would that cover a class that has been implemented to mask the enums from direct access, so if they need to be changed to dynamic or renamed or anything, the other repositories that are using them through this class won't be affected or need any update.

Did we not decide to revert all the changes back and the redesign the whole concept again?

Look in the td_defs.py for the same comment.

Look in the td_defs.py for the same comment.

Look in the td_defs.py for the same comment.

Look in the td_defs.py for the same comment.

This design is incorrect,
For common codes, a proxy or a wrapper class should have been implemented.
We will keep it for now to unblock the rest of the team.

This is incorrect.
We should not create many objects for all the Enum classes in an API, and we should not use memory that may not even be in use.
We will keep it for now to unblock the rest of the team.

When building locally without all the parameters the generated name throws an error during python pip install.
So this ensures that if no parameter is added, it uses the default name which is compatible with pip install.
The " -+. " sequence is throwing an error.

removed commented out line

It's a class containing all the enums of the def file.
Yes we need them as many other Framework and huge amount of code are using them.

Obviously not.
You were reminding me about backwards compatibility. This variable and class ensures that even with this major refactor to the enum structure, the current codebase remains working.

Yes, they are aliases that are used for example in Dialin's temperature sensor module to decide which msg id to use for the override.
Updating an alias's value when adding new entries to the enum is easier then changing the last or first sensor type across Dialin modules, which could be forgotten or missed.

DialinEnum from_str function using it to match a strung to an enum member. Converting the string to enum for cleaner code in test cases.

Yes

Not sure about this change. This script is used during the automated builds. Do you use this script anywhere else?

Treatment Params have been removed from firmware.

Are these part of FPTemperatureSensorName class?

same

same

What is the use of this dictionary?

same here

Same here.