Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Exploration of descriptors(Identifier class) over the favor of deprecating device decorator #53

Open
hiromon0125 opened this issue Dec 9, 2024 · 0 comments
Assignees

Comments

@hiromon0125
Copy link
Collaborator

hiromon0125 commented Dec 9, 2024

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

  • 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.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Backlog
Development

No branches or pull requests

2 participants