> On Sep 11, 2017, at 3:23 PM, Stefan Behnel <stefan...@behnel.de> wrote: > > Ryan Gonzalez schrieb am 11.09.2017 um 19:16: >> One thing I want to point out: there are a lot of really useful Python >> libraries that have come to rely on annotations being objects, ranging >> from plac to fbuild to many others. I could understand something that >> delays the evaluation of annotations until they are accessed, but this >> seems really extreme. > > I guess there could be some helper that would allow you to say "here's an > annotation or a function, here's the corresponding module globals(), please > give me the annotation instances".
Currently the PEP simply proposes using eval(ann, globals, locals) and even suggests where to take globals from. The problem is with nested classes or type annotations that are using local state. The PEP is proposing to disallow those due to the trickiness of getting the global and local state right in those situations. Instead, you'd use qualified names for class-level fields that you're using in your annotation. This change is fine for static use and runtime use, except when faced with metaclasses or class decorators which resolve the annotations of a class in question. So far it looks like both typing.NamedTuple and the proposed data classes are fine with this. But if you have examples of metaclasses or class decorators which would break, let me know! - Ł
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
