-
-
Notifications
You must be signed in to change notification settings - Fork 458
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
Refactor support for annotate
to utilise mypy.types.Instance.extra_attrs
#2319
Merged
Merged
Changes from 1 commit
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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 don't think that we should remove this feature. Because I see that a lot of users discuss this and use this. Maybe we can treat
WithAnnotations[MyModel]
asWithAnnotations[MyModel, Any]
implicitly? Via type var defaults or something?This way we can continue to support this code (maybe with a deprecation warning, why not). But breaking it - does not seem right to me :(
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.
But, I agree that we should not have done this in the first place.
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.
Yeah, I suppose, gonna have to see if I can get it working. The support for any/arbitrary attributes is a bit of work I think
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.
We only need to support
Any
, no other arguments / types.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.
Yes, the
Any
type argument is fine. But that doesn't add support for accessing an arbitrary attribute, like the previous implementation supported.Essentially you'll still get something like:
I don't have any solution that removes the "has no attribute" error.
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.
There's 1 problem that I see with that, unless I'm missing something, which is that
Model@AnnotatedWith[Any]
is anInstance
and not aTypeInfo
. But we need to add the__getattr__
method to theTypeInfo
though if we do, all instances ofModel@AnnotatedWith
gets the__getattr__
methodThere 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.
Won't
.extra_attrs
do the job for single instance__getattr__
? 🤔I am not sure, just asking.
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.
__getattr__
will work for the arbitrary attributes. But we still want/need to be able to match the model type on e.g. a function argument.This whole thing is kind of twofold.
WithAnnotations
as a function argumentextra_attrs
for accessing declared annotated attributes e.g. inside a function body__getattr__
would help out with attributes accessed inside the body. But I can't find a way to add it and keep 1. working and not affect all other instances. I've also tried adding the__getattr__
method toextra_attrs
with no luck:ExtraAttrs(attrs={"__getattr__": CallableType(...)}, ...)
There's also the
TypeInfo.fallback_to_any
which is the same as subclassingAny
or ourAnyAttrAllowed
. But same issue here, it affects the type and not instances of said type.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.
Thanks a lot for your research! Not really what I hoped for :(
In this case, let's do the cleanest solution and break
WithAnnotations[M]
usage in a way that we restrict known attributes.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 was also hoping to find a way that kept backwards compatibility. At least I'm hoping breaking this will make it a bit easier going forward.
Do you mean restrict known attributes like emitting
"has no attribute"
errors?Then, calling wise, if we replace
We can require that
.annotate
has been called, but we don't care with what. Just like before. I'm thinking this is the implementation we want.Else if we replace like (this is what we do now)
This wouldn't distinguish between having called
.annotate
or not. Meaning that there's no requirement of having called.annotate
but having done it is also accepted.