-
Notifications
You must be signed in to change notification settings - Fork 317
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
Add v1.6 data types #250
Add v1.6 data types #250
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suggest to remove the CiStringXXXType
and the IdToken
All other classes model a type; a bag of attributes. The CiStringXXXType
and IdToken
are merely a string with some limits on their length.
It also creates a non-friendly API. To read the value of the an IdTagInfo
:
assert IdTagInfo.parent_id_tag.id_token.ci_string_20 == 'my-rfid'
Ideally, I want the API to be:
assert IdTagInfo.parent_id_tag == 'my-rfid'
I'm not sure yet, a nice way to impose this length on attributes of type CiStringXXXType
and IdToken
. So for now I suggest that the length is not validated and replace the type hints of attributes using those types with str
. What do yo think?
I was debating adding them from the beginning. Then I debated adding some kind of custom validator, but I figured you might be against the complexity for such a small thing. To avoid a dependency I could use a post_init to verify the length of the string in IdTagInfo and remove the CiStringXXXType. Or I can just drop it all together and leave it as is. |
I like that solution |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The code looks good. Make sure to fix the lint errors so the CI job passes.
@OrangeTux fixed up the linting issues |
The `Authorize.conf` message in the v1.6 spec defines what fields should be present for an `IdTagInfo`. The dataclass for this already exists in `datatypes.py`, as of the recently merged #250 PR. This PR makes use of it by importing the dataclass, and using it instead of the more losely typed `typing.Dict`.
No description provided.