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

How to test type compatibility in Python 3.7? #570

Closed
Kimi-Arthur opened this issue Jul 7, 2018 · 4 comments
Closed

How to test type compatibility in Python 3.7? #570

Kimi-Arthur opened this issue Jul 7, 2018 · 4 comments

Comments

@Kimi-Arthur
Copy link

Kimi-Arthur commented Jul 7, 2018

With the new fixes done in Python 3.7. We cannot test type compatibility like:

type_info = List[int]
issubclass(type_info, list)

# Or

issubclass(type_info, List)

This is expected as mentioned in PEP560. So I'm not saying I should continue to write code like that.

But since it's still useful to inspect whether type is a list or not (e.g. when you inspect the object's type hints and generate a default value for it), I wonder whether these is already a known way to test such compatibility.

Thanks!

@Kimi-Arthur Kimi-Arthur changed the title How to test type compatibility in Python 3? How to test type compatibility in Python 3.7? Jul 7, 2018
@ilevkivskyi
Copy link
Member

One possible solution is to use typing_inspect library on PyPI, it has a get_origin() function which you can use as issubclass(get_origin(type_info), list).

But I think maybe it is time consider adding some basic introspection to typing? From all recent similar requests and general experience with typing_inspect it looks like people are interested mostly in two things:

  • Get an "erased" version of a type, i.e. a runtime class equivalent of a given type
  • Get type arguments from a given type

@gvanrossum Does it make sense to add such two helper functions that would be essentially public wrappers around internal APIs like .__origin__ and .__args__?

@gvanrossum
Copy link
Member

Yes. I like that we make these things functions in typing rather than special attributes or methods -- it's much easier for a function to do the right thing when the type given to it is some built-in or user-defined type rather than one of the special one from typing. It should also deal with forward reference strings.

@Kimi-Arthur
Copy link
Author

.__origin__ is already very helpful. Thanks! Didn't know that.

Besides the two features you suggest, I guess testing type (either actual type or typing's type variable, like _GenericAlias) compatibility would also be useful. If this would be automatically supported by those two features, it would still be worth mentioning in that particular release's notes. Thanks!

@ilevkivskyi
Copy link
Member

get_origin() (an official public API for .__origin__) got into typing in Python 3.8, so I think this can be closed now.

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

No branches or pull requests

3 participants