Uh oh!
There was an error while loading. Please reload this page.
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'm a bit surprised about this
bind_self, actually. I cannot find whereinferred_dunder_get_typegets passed tobind_self... I'm only looking at the code though. I'm certain it's used but... where?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.
Hum, in
analyze_descriptor_access, we passinferred_dunder_get_typeastarget:mypy/mypy/checkmember.py
Lines 726 to 728 in 9ff9946
but not sure what you mean exactly
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.
Like I'd expect some sort of symmetry: we repeat the actions we did to get target on each overload member. But I can't find where we
bind_self.To be specific, in
analyze_descriptor_access(or in a function it calls) I expect abind_selfcall asdunder_getturns intoinferred_dunder_get_type... but I can't find one. Is it just not necessary?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.
analyze_descriptor_accesscallsanalyze_decorator_or_funcbase_access(eventually) callsbind_self. Is that what you are looking for?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.
Yep! Does that mean
bind_selfandexpand_type_by_instanceshould be swapped (IE pass the result ofbind_selftoexpand_type_by_instance) in this PR?I'm not sure if there's a difference anyways but I think it's better to imitate what's elsewhere.
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.
Without spending much time, I can also only speculate if these different orders can make a difference. But I guess you are right. Synchronising both steps as well as possible should do no harm and might be beneficial in some cases. (At least, it frees the next one looking at the code from asking himself the same question.)
bind_selfgetsdescriptor_typebutexpand_type_by_instancegetstyp. Same question here?