Ken Jin <kenjin4...@gmail.com> added the comment:

> 1. By adding the same `_type_check` logic we can reduce the inconsistency 
> between two versions. It would be easier for users to migrate from one 
> version to another.

That's definitely a plus. But please consider this hypothetical scenario:

- Let's say some typing code has _type_check in 3.8
- In 3.12, we decide to give type hinting with ints (like `x: 1`) some meaning 
(this has been proposed before in typing-sig).
- The new construct arrives in 3.12. We backport to typing_extensions, which 
*must* support 3.8's typing module.
- Now the new addition to 3.12 typing_extensions doesn't work with 3.8 typing 
because of _type_check, and we need to hack around it.
- The hacks may eventually lead to real behavioral inconsistencies between 
typing_extensions and typing.

If this sounds familiar, that's because something similar has already happened! 
Callable and Generic had too strict checking in typing (requiring Callable's 
args to be a tuple of types always) before 3.10. So typing_extensions doesn't 
support the full PEP 612 syntax :( 
https://github.com/python/typing/tree/master/typing_extensions#other-notes-and-limitations.

Stricter runtime type checking makes growing the typing syntax harder. For the 
newer types, we try to defer checking to 3rd-party libraries.

> Because I received quite a lot of bug reports from users involving different 
> behavior with / without `__future__` import of `annotations`.

Your perspective as a runtime typing library dev is very valuable. Thank you 
for your feedback! IMO, `from __future__ import annotations` becoming the 
default in 3.11 is still undecided. It was yanked from 3.10 for breaking 
pydantic and FastAPI, and I doubt it will land in 3.11 for the same reasons. It 
seems the current consensus is to use that import for code with purely static 
typing, and not use it with runtime typing libraries.

----------

_______________________________________
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue45283>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to