-
-
Notifications
You must be signed in to change notification settings - Fork 374
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
Flesh out resolve_types #1099
Flesh out resolve_types #1099
Conversation
@hynek vroom vroom? |
Do we know someone who knows what any of this means and could review? |
Hello. Happy to review. So this is backwards incompatible change because before the default was for From the get_type_hints documentation: So I guess my question is if we're happy with the documentation of "this resolves the types more accurately." |
You're right in that this is technically backwards incompatible, I made the call with the following assumptions:
Happy to change the default if you folks think that's the right call. As for the docs, happy to be more precise if we think that'll be useful to the readers. |
I wonder if for the docs it could say that the value is passed in to get_type_hints and leave it at that. Since it's possible the definition of include_extras could change in the future? (As in maybe it does more than Annotated and now our docs would be out of date with python.). But that's a pretty minor difference all things considered. As to the default value, I'm of 2 minds. It's nice when you get the latest and greatest by default. However I'm not sure I like that our default is the opposite of python's. That being said, our method is not called the same as theirs so it might be ok to reverse the default here. |
Yeah I think I'm fine with this "breakage" since nobody except Tin is using |
Eh sorry, was this ready for merge? |
Yeah, barring any bikeshedding around the docs. |
Trying to improve
resolve_types
.