Skip to content
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

Merged
merged 7 commits into from
Mar 18, 2023
Merged

Flesh out resolve_types #1099

merged 7 commits into from
Mar 18, 2023

Conversation

Tinche
Copy link
Member

@Tinche Tinche commented Feb 2, 2023

Trying to improve resolve_types.

@Tinche
Copy link
Member Author

Tinche commented Feb 2, 2023

@hynek vroom vroom?

@hynek
Copy link
Member

hynek commented Feb 3, 2023

Do we know someone who knows what any of this means and could review?

@euresti
Copy link
Contributor

euresti commented Feb 4, 2023

Hello. Happy to review.

So this is backwards incompatible change because before the default was for include_extras=False and we've change it to be True. I'm not sure this is a complete deal breaker though as this variable only matters when using Annotated.
See https://peps.python.org/pep-0593/#interaction-with-get-type-hints

From the get_type_hints documentation:
The function recursively replaces all Annotated[T, ...] with T, unless include_extras is set to True (see Annotated for more information).

So I guess my question is if we're happy with the documentation of "this resolves the types more accurately."

@Tinche
Copy link
Member Author

Tinche commented Feb 4, 2023

You're right in that this is technically backwards incompatible, I made the call with the following assumptions:

  • the change is relatively minor (I'm not aware of any use case other than Annotated at this time, I think)
  • the change will affect very few users (subjective, because no one has opened an issue about not having access to Annotated via resolve_types)
  • the new default is, IMO, more correct so I'd prefer to suffer a little pain now rather than drag the bad default on forever

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.

@euresti
Copy link
Contributor

euresti commented Feb 4, 2023

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.

@hynek
Copy link
Member

hynek commented Feb 6, 2023

Yeah I think I'm fine with this "breakage" since nobody except Tin is using Annotated and this seems still like a beta feature. Hiding it behind an option would give us another auto_attribs=True.

@hynek
Copy link
Member

hynek commented Mar 18, 2023

Eh sorry, was this ready for merge?

@Tinche
Copy link
Member Author

Tinche commented Mar 18, 2023

Yeah, barring any bikeshedding around the docs.

@hynek hynek merged commit c7308a6 into main Mar 18, 2023
@hynek hynek deleted the tin/fix-resolve-types branch March 18, 2023 18:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants