You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently due to the limitation of class decorators in python and undocumented unknown behaviors caused by the device decorator, it adds huge technical debt and ideally would like to create a different more stable solution, if possible, so that it is also very intuitive and well documented. This comes from a lot of the bugs found during testing. We found that the class decorator changes the meta class of the device class which causes us to have a hard time type checking for sub-device class in the parent device class's decorator. This is a feature where we can use a parameter of sub-device in the location of the sub-device param in the parent device class. This allows us to auto-declare sub-device in the param of parent device in the pinconfig.
Bug list
Slots in dataclass decorator causes the program to break
_identifier is needed error (Temporarily fixed)
device class is not of type "some device class type" (Temporarily fixed)
Current functionality/feature
Currently as a function of device decorator, all the device decorator does is sees each class attribute and find the Identifier descriptors which is not a correct use of descriptors as it does nothing but holds context object. Identifier class basically acts as a marker for the decorator. Once the decorator finds the identifier class it, remembers the attributes and during initialization of the device class it checks the types of the parameter it receives and if it is not a sub-device class then uses the parser function in the context held in the identifier class to create a new instance of the class. Once the instance is created it autogenerates the identifier and stores it in the sub-device context.
This is implemented such that we can use a parameter of the sub-device into the parameter of the device class and during the initialization of the device class, the instance of the sub-device class is made before storing the identifier of the sub-device into the device class.
Solution
With the way correct implementation of the descriptor class, it might be possible to deprecate the device decorator all together.
For example, in the __set__ function we could type check and if it is not a sub-device then we can make a new instance and auto-generate the sub-device identifier and set the instance in the sub-device context. If its a string we can just store that as it should be an identifier(We can also check to see if the sub-device context has that correct identifier). In the __get__ we can just return a sub-device identifier; this is done so that action function in the parent can not modify or call function on the instance of the sub-device.
The identifier string is formatted in the following order to improve readability: ${parent_class_identifier}.${parent_class_attribute_name}. This requires us to magically receive parent_class_identifier which might be proven to be difficult, so additional functionality may be added to the parser function.
This should solve the bug, technical debt, and intuition of the implementation.
Something that needs to be tested is its compatibility with dataclass decorator. Due to the fact that the decorator will see the identifier in the class, it might have weird side effect, so definitely test around that and see if theres any issue.
Description
Currently due to the limitation of class decorators in python and undocumented unknown behaviors caused by the device decorator, it adds huge technical debt and ideally would like to create a different more stable solution, if possible, so that it is also very intuitive and well documented. This comes from a lot of the bugs found during testing. We found that the class decorator changes the meta class of the device class which causes us to have a hard time type checking for sub-device class in the parent device class's decorator. This is a feature where we can use a parameter of sub-device in the location of the sub-device param in the parent device class. This allows us to auto-declare sub-device in the param of parent device in the pinconfig.
Bug list
Current functionality/feature
Currently as a function of device decorator, all the device decorator does is sees each class attribute and find the Identifier descriptors which is not a correct use of descriptors as it does nothing but holds context object. Identifier class basically acts as a marker for the decorator. Once the decorator finds the identifier class it, remembers the attributes and during initialization of the device class it checks the types of the parameter it receives and if it is not a sub-device class then uses the parser function in the context held in the identifier class to create a new instance of the class. Once the instance is created it autogenerates the identifier and stores it in the sub-device context.
This is implemented such that we can use a parameter of the sub-device into the parameter of the device class and during the initialization of the device class, the instance of the sub-device class is made before storing the identifier of the sub-device into the device class.
Solution
With the way correct implementation of the descriptor class, it might be possible to deprecate the device decorator all together.
For example, in the
__set__
function we could type check and if it is not a sub-device then we can make a new instance and auto-generate the sub-device identifier and set the instance in the sub-device context. If its a string we can just store that as it should be an identifier(We can also check to see if the sub-device context has that correct identifier). In the__get__
we can just return a sub-device identifier; this is done so that action function in the parent can not modify or call function on the instance of the sub-device.The identifier string is formatted in the following order to improve readability:
${parent_class_identifier}.${parent_class_attribute_name}
. This requires us to magically receive parent_class_identifier which might be proven to be difficult, so additional functionality may be added to the parser function.This should solve the bug, technical debt, and intuition of the implementation.
Something that needs to be tested is its compatibility with dataclass decorator. Due to the fact that the decorator will see the identifier in the class, it might have weird side effect, so definitely test around that and see if theres any issue.
Reference
https://docs.python.org/3/howto/descriptor.html
User story
As a tester, I want to be able to reliably check the device class so its intuitive.
The text was updated successfully, but these errors were encountered: