On Thu, Oct 21, 2021 at 10:44 AM Damian Shaw <damian.peter.shaw@gmail.com> wrote:
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?
Yes, you're right. And I don't think PEP 649 and PEP 563 are really all that different in this regard: if you have an annotation using a non-imported name, you'll be fine as long as you don't introspect it at runtime. If you do, you'll get a NameError. And with either PEP you can work around this if you need to by ensuring you do the imports first if you're going to need the runtime introspection of the annotations. The difference is that PEP 563 makes it easy to introspect the annotation _as a string_ without triggering NameError, and PEP 649 takes that away, but I haven't seen anyone describe a really compelling use case for that.
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?
It could, but this makes evaluation of annotations oddly different from evaluation of any other code, which is something that it's reasonable to try to avoid if possible. Carl