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.
Predict enum value type for unknown member names. #9443
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
Predict enum value type for unknown member names. #9443
Changes from all commits
fa67a31
077d3e7
e861117
db16871
bfee76d
b3653d7
f1adaf5
22c1474
aae9de3
d392d05
050fdc2
5fa5a93
5b8baa9
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
If I read the docstring of
get_proper_type()
correctly, it suggest that here you should actually be returningfirst_node_type
. And in fact, perhaps you should probably adjust theall()
check to go throughget_proper_type() instead?
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 took a stab at this, but I'm not completely sure what you're saying here :). It's unclear to me whether the result of
enum_value_callback
should be aProperType
or not. The existing code seems to try to return aProperType
so I just followed suit there. I did change the "all-equal" to compare the entities after figuring out theirProperType
though.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.
Hm, I think I misunderstood this. I thought that using
get_proper_type()
would distinguishA
fromint
if we havebut it doesn't seem to work that way. So you're forgiven for not understanding me. :-)
I think what you have now is fine.
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 wonder if this shouldn't infer
object
instead ofAny
?In favor of
Any
: That's what we did before in this case; it prevents false positives.In favor of
object
: That's what you'd see for e.g.reveal_type("" if a else 0)
, assuminga
has an unknown value.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 trying to just follow the existing art. I imagine that changing to
object
could cause some code to fail with false positives (If a user is actually using the.value
, it seems unlikely that they will be restricting themselves to the interface provided byobject
so this would probably force them to do additionalcast
or other methods of type-narrowing)With that said ... once this is implemented, it shouldn't matter to me either way. Hopefully
mypy
will know the types of all of my enum values since I see no reason for inhomogenous values and it should never bother me in either case :). I'll do whatever you like.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.
1E80Okay, let's stick with tradition and keep
Any
.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.
Shenanigans are happening here -- I'm not sure the best way to do this. If I use the signature (as written in
typeshed
), we end up with:That pulls in
staticmethod
which doesn't have a stub inlib-stub
. From that point, there are a bunch of different ways we can lie (e.g. just add aself
and drop thestaticmethod
), but it seems to me like a little lie is just as harmful as a big one (maybe more because it's less likely to be noticed).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 this comment is all we need if in the future mypy and/or the test fixtures somehow get clever enough to notice the signature mismatch.