I still prefer PEP 563. I will describe what we lost if PEP 597 is accepted and PEP 563 is rejected.
### Types not accessible in runtime First of all, PEP 563 solves not only forward references. Note that PEP 563 says: "we'll call any name imported or defined within a `if TYPE_CHECKING: block` a forward reference, too." https://www.python.org/dev/peps/pep-0563/#forward-references PEP 563 solves all problems relating to types not accessible in runtime. There are many reasons users can not get types used in annotations at runtime: * To avoid circular import * Types defined only in pyi files * Optional dependency that is slow to import or hard to install This is the most clear point where PEP 563 is better for some users. See this example: ``` from dataclasses import dataclass if 0: from fakemod import FakeType @dataclass class C: a : FakeType = 0 ``` This works on PEP 563 semantics (Python 3.10a7). User can get stringified annotation. With stock semantics, it cause NameError when importing so author can notice they need to quote "FakeType". With PEP 649 semantics, author may not notice this annotation cause error. User can not get any type hints at runtime. ### Type alias Another PEP 563 benefit is user can see simple type alias. Consider this example. ``` from typing import * AliasType = Union[List[Dict[Tuple[int, str], Set[int]]], Tuple[str, List[str]]] def f() -> AliasType: pass help(f) ``` Currently, help() calls `typing.get_type_hints()`. So it shows: ``` f() -> Union[List[Dict[Tuple[int, str], Set[int]]], Tuple[str, List[str]]] ``` But with PEP 563 semantics, we can stop evaluating annotations and user can see more readable alias type. ``` f() -> AliasType ``` As PEP 597 says, eval() is slow. But it can avoidable in many cases with PEP 563 semantics. I am not sure but I expect dataclass can avoid eval() too in PEP 563 semantics. Sphinx uses this feature already. See https://www.sphinx-doc.org/en/master/usage/extensions/autodoc.html#confval-autodoc_type_aliases ### Relaxing annotation syntax As discussed in PEP 647 thread, we can consider having different syntax for annotation with PEP 597 semantics. Regards, On Mon, Apr 12, 2021 at 10:58 AM Larry Hastings <la...@hastings.org> wrote: > > > Attached is my second draft of PEP 649. The PEP and the prototype have both > seen a marked improvement since round 1 in January; PEP 649 now allows > annotations to refer to any variable they could see under stock semantics: > > Local variables in the current function scope or in enclosing function scopes > become closures and use LOAD_DEFER. > Class variables in the current class scope are made available using a new > mechanism, in which the class dict is attached to the bound annotation > function, then loaded into f_locals when the annotation function is run. > Thus permitting LOAD_NAME opcodes to function normally. > > > I look forward to your comments, > > > /arry > > _______________________________________________ > Python-Dev mailing list -- python-dev@python.org > To unsubscribe send an email to python-dev-le...@python.org > https://mail.python.org/mailman3/lists/python-dev.python.org/ > Message archived at > https://mail.python.org/archives/list/python-dev@python.org/message/QSASX6PZ3LIIFIANHQQFS752BJYFUFPY/ > Code of Conduct: http://python.org/psf/codeofconduct/ -- Inada Naoki <songofaca...@gmail.com> _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/KK5QG75RWSDBU4E36XAVSDPY5OUERA73/ Code of Conduct: http://python.org/psf/codeofconduct/
