Sorry for the naive question but why doesn't "TYPE_CHECKING" work under PEP 649?
I think I've seen others mention this but as the code object isn't executed until inspected then if you are just using annotations for type hints it should work fine? Is the use case wanting to use annotations for type hints and real time inspection but you also don't want to import the objects at run time? If that's really such a strong use cause couldn't PEP 649 be modified to return a repr of the code object when it gets a NameError? Either by attaching it to the NameError exception or as part of a ForwardRef style object if that's how PEP 649 ends up getting implemented? Damian (he/him) On Thu, Oct 21, 2021, 00:05 Henry Fredrick Schreiner < henry.fredrick.schrei...@cern.ch> wrote: > > typing features from future Python versions > > I second both of these uses, but especially this (which seems to be > missing from the original post), it’s been by far the main reason I’ve used > this mode and I’ve seen this used, and is the main feature to look forward > to when dropping Python 3.7 support. The new features coming to typing make > static typing much easier, but no libraries can drop Python 3.7/3.8/3.9 > support; but static typing doesn’t need old versions. > > When talking about speed, one of the important things to consider here is > the difference between the two proposals. PEP 649 was about the same as the > current performance, but PEP 563 was significantly faster, since it doesn’t > instantiate or deal with objects at all, which both the current default and > PEP 563 do. You could even protect imports with TYPE_CHECKING with PEP 563, > and further reduce the runtime cost of adding types - which could be seen > as a reason to avoid adding types. To the best of my knowledge, it hasn’t > been a blocker for packages, but something to include. > > Also, one of the original points for static typing is that strings can be > substituted for objects. “Type” is identical, from a static typing > perspective, to Type. You can swap one for the other, and for a Python 3.6+ > codebase, using something like “A | B” (with the quotes) is a valid way > to have static types in 3.6 that pass MyPy (though are not usable at > runtime, obviously, but that’s often not a requirement). NumPy, for > example, makes heavy usage of unions and other newer additions in static > typing. > _______________________________________________ > 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/L3IKBO5YZNQ2B5Y6VA7KX352VCOCQEBB/ > Code of Conduct: http://python.org/psf/codeofconduct/ >
_______________________________________________ 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/YZYND5RYBZRRCZY7J3HSE5RXP4JTUENC/ Code of Conduct: http://python.org/psf/codeofconduct/
