Great. If you’d like to add something to the docs for get_type_hints() about this behavior please submit a PR — I don’t see a reason this would suddenly change but it’s better to make sure.
On Tue, Dec 8, 2020 at 22:29 Paul Bryan <pbr...@anode.ca> wrote: > 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/ > > > -- --Guido (mobile)
_______________________________________________ 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/K6YY6LLMMV5KB4YUQME2CDGAHEIG6XF6/ Code of Conduct: http://python.org/psf/codeofconduct/
