[Python-ideas] PEP 563 and expensive backwards compatibility
Nick Coghlan
ncoghlan at gmail.com
Wed Sep 13 18:37:54 EDT 2017
On 14 September 2017 at 06:01, Jim J. Jewett <jimjjewett at gmail.com> wrote:
> The "right time" is whenever they are currently evaluated.
> (Definition time, I think, but won't swear.)
>
> For example, the "annotation" might really be a call to a logger,
> showing the current environment, including names that will be rebound
> before the module finishes loading.
>
> I'm perfectly willing to agree that even needing this much control
> over timing is a code smell, but it is currently possible, and I would
> rather it not become impossible.
>
> At a minimum, it seems like "just run this typing function that you
> should already be using" should either save the right context, or the
> PEP should state explicitly that this functionality is being
> withdrawn. (And go ahead and suggest a workaround, such as running
> the code before the method definition, or as a decorator.)
I think it would be useful for the PEP to include a definition of an
"eager annotations" decorator that did something like:
def eager_annotations(f):
ns = f.__globals__
annotations = f.__annotations__
for k, v in annotations.items():
annotations[k] = eval(v, ns)
return f
And pointed out that you can create variants of that which also pass
in the locals() namespace (or use sys._getframes() to access it
dynamically).
That way, during the "from __future__ import lazy_annotations" period,
folks will have clearer guidance on how to explicitly opt-in to eager
evaluation via function and class decorators.
Cheers,
Nick.
--
Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
More information about the Python-ideas
mailing list