-
-
Notifications
You must be signed in to change notification settings - Fork 631
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
Support fingerprinting of UnsetBool
options.
#4665
Support fingerprinting of UnsetBool
options.
#4665
Conversation
This was a landmine waiting to go off. All other supported option custom types were handled.
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.
whoa. Did not know that this existed.
Thanks.
|
||
|
||
class Encoder(json.JSONEncoder): | ||
_UNSET_BOOL_ENCODING = '__type::{}::{}'.format(inspect.getmodule(UnsetBool), UnsetBool.__name__) |
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.
Why is the inspect magic needed? Couldn't this just be UnsetBool.__module__
, or even a hard-coded string? I mean, apart from readability concerns _UNSET_BOOL_ENCODING
can be literally any unlikely-to-collide string, if I understand this correctly?
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.
It could be anything - eye of beholder I guess. I look at __module__
, __package__
and throw up my hands as to which will be available when. I figure inspect
gets this right robustly.
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.
Well, as long as it's not a performance liability, which it probably isn't. My suspicion of introspection is a JVM holdover, in Python introspection is part of the bargain, I guess.
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.
Do we actually care what module this is in though? Would we want to invalidate if we renamed the module?
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.
Well, as long as it's not a performance liability ....
Its a class constant, so no real concern
Do we actually care what module this is in though?
No, just that it doesn't collide with other strings. Open to a concrete suggestion on what value makes sense.
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 think '_UNSET_BOOL_ENCODING'
as the value makes sense?
Sorry to harp on this, I just imagine (or another casual reader) looking at this in the future and wondering why we want to invalidate options fingerprints if we change the name or location of an implementation detail. A constant literal string is fairly idiomatic for "symbolic constant value whose actual content isn't significant, only its uniqueness".
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.
Sounds good - unlikely to collide.
This was a landmine waiting to go off. All other supported option custom
types were handled.