On Tue, Apr 26, 2022 at 1:25 PM Guido van Rossum <gu...@python.org> wrote: > I also would like to hear more about the problem this is trying to solve, > when th real-world examples. (E.g. from pydantic?)
Yes please. I think these threads have jumped far too quickly into esoteric details of implementation and syntax, without critical analysis of whether the semantics of the proposal are in fact a good solution to a real-world problem that someone has. I've already outlined in a more detailed reply on the first thread why I don't think forward declarations provide a practically useful solution to forward reference problems for users of static typing (every module that imports something that might be a forward reference would have to import its implementation also, turning every one-line import of that class into two or three lines) and causes new problems for every user of Python due to its reliance on import side effects causing global changes at a distance. See https://mail.python.org/archives/list/python-dev@python.org/message/NMCS77YFM2V54PUB66AXEFTE4NXFHWPI/ for details. Under PEP 649, forward references are a small problem confined to the edge case of early resolution of type annotations. There are simple and practical appropriately-scoped solutions easily available for that small problem: providing a way to resolve type annotations at runtime without raising NameError on not-yet-defined names. Such a facility (whether default or opt-in) is practically useful for many users of annotations (including dataclasses and documentation tools), which have a need to introspect some aspects of annotations without necessarily needing every part of the annotation to resolve. The existence of such a facility is a reasonable special case for annotations specifically, because annotations are fundamentally special: they provide a description of code, rather than being only a part of the code. (This special-ness is precisely also why they cause more forward references in the first place.) IMO, this forward declaration proposal takes a small problem in a small corner of the language and turns it into a big problem for the whole language, without even providing as nice and usable an option for common use cases as "PEP 649 with option for lax resolution" does. This seems like a case study in theoretical purity ("resolution of names in annotations must not be special") running roughshod over practicality. Carl _______________________________________________ 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/RVQSLD435BFKEVIMY2AIA5MCJB37BPHK/ Code of Conduct: http://python.org/psf/codeofconduct/
