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

Trying to resolve or register 'metadata' like typing.Annotated should be an error #3280

Closed
14 tasks done
Zac-HD opened this issue Apr 2, 2022 · 3 comments
Closed
14 tasks done
Labels
legibility make errors helpful and Hypothesis grokable

Comments

@Zac-HD
Copy link
Member

Zac-HD commented Apr 2, 2022

Based on the typing module docs, here's a list of 'metadata types'. We should raise an explicit error if the user attempts to register or resolve them.

  • Annotated - Resolves strategies from Annotated type #3082 handled the cases where we want to resolve it; but we still need to ban registering it or attempting to resolve bare Annotated
  • ClassVar
  • Final
  • TypeAlias
  • Concatenate and ParamSpec can never be registered or resolved
    • and the Callable resolver should give a specific error message if it sees these types
  • TypeGuard can never be registered, returns st.booleans() for any inner type.
    • resolving a callable with a TypeGuard return annotation should be an explicit error (per the PEP and because we can't actually produce such callables)
  • Self type (ban)
  • Never (like NoReturn)
  • TypeVarTuple
  • Unpack
  • LiteralString can be banned for now; we can revisit later.
  • Required and NotRequired (ban registration, resolve as inner type or error if bare). They are already implemented in typing_extensions and mypy

(replaces #2978 to omit rambling discussion while we worked out what to do)

@Zac-HD Zac-HD added the legibility make errors helpful and Hypothesis grokable label Apr 2, 2022
@Cheukting
Copy link
Contributor

I will first add all the types that we straightly ban if having no args in the NON_RUNTIME_TYPES then will look at the individual ones seperately.

@Cheukting
Copy link
Contributor

The only task that #3331 does not cover is the resolver for Required and NotRequired

@Zac-HD
Copy link
Member Author

Zac-HD commented May 11, 2022

Opened a new issue just for that remaining task, since it's quite different to banning the unresolvable types 👍

Thanks again Cheuk!

@Zac-HD Zac-HD closed this as completed May 11, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
legibility make errors helpful and Hypothesis grokable
Projects
None yet
Development

No branches or pull requests

2 participants