[issue34568] Types in `typing` not anymore instances of `type` or subclasses of "real" types

Jelle Zijlstra added the comment: More recent versions of typing have added some helper functions that could be useful here, like typing.get_origin and typing.get_args. I'm going to close this issue because I don't think there's anything actionable. -- nosy: +Jelle Zijlstra

[issue34568] Types in `typing` not anymore instances of `type` or subclasses of "real" types

Pekka Klärck added the comment: You are obviously right with how `__instancecheck__` and `__subclasscheck__` work. We'd either need something like `__rinstancecheck__` and `__rsubclasscheck__` or `isinstance` and `issubclass` needed to handle this using `types.resolve_bases`, `__origin__`,

[issue34568] Types in `typing` not anymore instances of `type` or subclasses of "real" types

Ivan Levkivskyi added the comment: > but even then types in the typing could themselves implement > `__instancecheck__` and `__subclasscheck__` and retain the old behavior. It doesn't work that way. `__instancecheck__` and `__subclasscheck__` tweaks the behaviour of superclass (i.e. the

[issue34568] Types in `typing` not anymore instances of `type` or subclasses of "real" types

Pekka Klärck added the comment: My concerns with the behavior of `__origin__` possibly changing in the future seem to valid. In Python 3.5 and 3.6 the behavior is List.__origin__ is None List[int].__origin__ is List while in Python 3.7 List.__origin is list

[issue34568] Types in `typing` not anymore instances of `type` or subclasses of "real" types

Pekka Klärck added the comment: While studying the types in the typing module more, I noticed they have a special `__origin__` attribute which seems to contain the "real" type they represent. I was able to make my type conversion code to work by adding these lines: if hasattr(type_,

[issue34568] Types in `typing` not anymore instances of `type` or subclasses of "real" types

Pekka Klärck added the comment: Thanks for the PEP-560 reference. It explains the reasoning for the underlying changes, performance, and also mentions backwards incompatibility problems, including `issubclass(List[int], List)` causing a TypeError. It doesn't mention that `issubclass(List,

[issue34568] Types in `typing` not anymore instances of `type` or subclasses of "real" types

Ivan Levkivskyi added the comment: It was a deliberate decision. You can find some motivation in PEP 560, and yes we used provisional status here. It was a hard decision, but we decided that giving up few percent of backwards compatibility is a reasonable price for up to 5x performance

[issue34568] Types in `typing` not anymore instances of `type` or subclasses of "real" types

Change by Serhiy Storchaka : -- components: +Library (Lib) versions: +Python 3.7, Python 3.8 ___ Python tracker ___ ___

[issue34568] Types in `typing` not anymore instances of `type` or subclasses of "real" types

Change by Serhiy Storchaka : -- nosy: +gvanrossum, levkivskyi ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34568] Types in `typing` not anymore instances of `type` or subclasses of "real" types

Pekka Klärck added the comment: Basically I'd like to get answers to these two questions: 1. Are the changes deliberate and covered by the fact that typing is a provisional module, or could the old functionality be restored? 2. If we cannot get the old functionality back, is there some other

[issue34568] Types in `typing` not anymore instances of `type` or subclasses of "real" types

New submission from Pekka Klärck : = Introduction = In Python 3.5 and 3.6 types defined in the typing module are instances of `type` and also subclasses of the "real" type they represent. For example, both `isinstance(typing.List, type)` and `issubclass(typing.List, list)` return true. In