Rereading PEP 563, I'm clearly railing against it. I believe I can work with __annotations__ as you suggest assuming the contract going forward is for get_type_hints to return annotations verbatim if they're not strings or ForwardRefs (the current implementation).
Thank you and Gregory for your time. On Tue, 2020-12-08 at 21:49 -0800, Guido van Rossum wrote: > On Tue, Dec 8, 2020 at 8:58 PM Paul Bryan <pbr...@anode.ca> wrote: > > My use case is to for type annotations to resolve type encoders, > > decoders and validators at runtime. > > > > > What is the reason you can't insist that the annotations be globals > or at least accessible from there (e.g. class attributes)? If the > reason is that they're dynamically computed, maybe you can > dynamically compute the annotation (effectively overruling the > "future" semantics)? `__annotations__` is a mutable attribute so > there's nothing to stop you from writing e.g. > > def make_foo(symbol): > def foo(arg: symbol): ... > foo.__annotations__['arg'] = symbol # Or you could do e.g. this > in a decorator > return foo > > > Without __future__, type annotations specified in closure scope are > > correctly attached to class variables, function parameters and > > return types. Because they're in scope at the time they're > > evaluated. > > > > __future__ annotations breaks because the hint is not evaluated > > until get_type_hints is called, which is too late; the scope is > > lost. > > > > Instead of just storing an annotation as a string, how about > > storing an object containing the string, plus the local scope? Then > > get_type_hint could be made to successfully resolve it. > > > > > That would be a problem because it would keep everything in the local > scope alive forever (since perhaps the annotation is never used). > > There may be a reason why my suggestion won't work either. If that's > so, please show a realistic example that captures the essence of your > problem, so we won't keep going back and forth attacking each other's > toy examples. > > Also please understand that this behavior is prescribed by an > accepted PEP and has been around since 3.7, so the bar to change this > is very high. (It's not the default behavior until 3.10 though, so > theoretically there might be a little bit more wiggle room for that. > So far you haven't shown sufficient evidence to consider that > though.) > > _______________________________________________ > 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/DMHM5BTBITZK26NJ2SZOOCYYK7AFWXFC/ > 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/KXMVS4EE4JHW6GPMECNN3Q4ZKJJCNQEH/ Code of Conduct: http://python.org/psf/codeofconduct/
