Guzz-T noted in #132 that we have changed some names since 0.3.14, in particular, Unknown_Calculation_239 has been changed to VBO_Temp_Spread_Soll. I suspect that this will also happens many times in the future.

Users of our library will find that Unknown_Calculation_239 will no longer work after an update and in some occasions, it might be quite cumbersome to find out the new name. (For Unknown_Calculation_239 it is pretty obvious, that this is calculation 239, but in other cases this might not be true).

I think that we should maintain a list of changes of these names, i.e., something like

changed_names = {
    "Unknown_Calculation_239" : "VBO_Temp_Spread_Soll"
}

in constants.py. Then, DataVector._lookup could also resolve old names (and maybe spit out a warning that users can change their code?).

• If we do so, we should also set up a unit test, which assures that all old names can be resolved.
• There seems to be one limit to the approach: We can't resolve the situation where "ID_BarFoo" is mapped to parameter 42 in 0.3.14 but is mapped to 23 in 0.3.15. However, this does not seem to be a big deal, since we can (almost) freely choose the parameter names.
• What about ID_WEB_SoftStand? This old calculation will be replaced by a higher level function. I think that an access of this old name should result in a meaningful error message. Maybe we can add a dictionary obsolete_names which contains these error messages, e.g.,

obsolete_names = {
    "ID_Web_SoftStand" : 'This parameter has be replaced by the function "get_firmware_version()" of LuxtronikData / Luxtronik.'
}