Currently two classes are used to create the EPOS4ObjDict in src/helpers.py. This happened because there was a desire to originally have an ObjDict class that contains different object dictionaries for different controller hardware. This eventually became EPOS4ObjDict. The idea was that the EPOS4Obj class could be used with python's isinstance() function to perform checks. This would have paired well with device discovery, so that a device could be automatically paired with its corresponding object dictionary, and enforce device specific functionality.
The problem is that its desirable to have the EPOS4ObjDict/ObjDict class to support the Enum class to perform helpful searches. The use of Enum made the original intent of ObjDict and EPOS4Obj unachievable because the type() and isinstance() functions evaluate everything in the ObjDict/EPOS4ObjDict as Enum.
I couldn't find a satisfactory solution with python's typing module, mainly because custom types are actually defined as function handles/pointers.
Currently two classes are used to create the
EPOS4ObjDictinsrc/helpers.py. This happened because there was a desire to originally have anObjDictclass that contains different object dictionaries for different controller hardware. This eventually becameEPOS4ObjDict. The idea was that theEPOS4Objclass could be used with python'sisinstance()function to perform checks. This would have paired well with device discovery, so that a device could be automatically paired with its corresponding object dictionary, and enforce device specific functionality.The problem is that its desirable to have the
EPOS4ObjDict/ObjDictclass to support theEnumclass to perform helpful searches. The use ofEnummade the original intent ofObjDictandEPOS4Objunachievable because thetype()andisinstance()functions evaluate everything in theObjDict/EPOS4ObjDictasEnum.I couldn't find a satisfactory solution with python's typing module, mainly because custom types are actually defined as function handles/pointers.