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

Annotated/get_type_hints interaction in python <3.11 #310

Open
DanCardin opened this issue Dec 7, 2023 · 3 comments · May be fixed by #312
Open

Annotated/get_type_hints interaction in python <3.11 #310

DanCardin opened this issue Dec 7, 2023 · 3 comments · May be fixed by #312

Comments

@DanCardin
Copy link

I'm not sure if you're aiming for exact compatibility among python versions for all of the functions you support or not.

But due to python/cpython#90353, get_type_hints with include_extras=True has inconsistent behavior among python versions below 3.11.

  • def foo(bar: Annotated[Union[int, None]]) -> Annotated[Union[int, None]]
  • def foo(bar: Annotated[Union[int, None]] = None) -> Optional[Annotated[Union[int, None]]]

I see #94, which mentions not wanting to do more rigorous porting due to it cascading into more code needing to be pulled in, so I'm not sure what the reaction to this will be...

@JelleZijlstra
Copy link
Member

The general aim is to reflect the behavior on most recent CPython, regardless of the Python version where typing-extensions is run. We're less likely to backport if:

  • The changed behavior is very obscure
  • The behavior only affects versions that are about to go EOL (e.g., at this point I wouldn't be enthusiastic about backporting a fix that only affects 3.8)
  • The fix in typing-extensions would be very invasive

In this case, the behavior isn't all that obscure and it affects versions that still have a few years of life in them, so I'd be willing to accept it as long as it doesn't get too complex. I'm OK with copying over more of get_type_hints if that's what it takes.

@DanCardin
Copy link
Author

The above PR represents a very bruteforce approach, namely in that it's not clear to me how to arrive at parity to the old, seeming much simpler, mechanism without first copying the whole implementation of get_type_hints, which then cascades through ForwardRef, a number of supporting functions.

Although at the same time, I noticed a number of potentially public-facing difference with ForwardRef itself.

The fact that typing is the way it is, and is as version specific as it is seems rather sad tbh.

@purepani
Copy link

I'm thinking this issue is what has been causing some issues using fastapi between 3.11 and versions below it; is there desire to have more discussion/move this forward a bit?

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 a pull request may close this issue.

3 participants