On 14 September 2017 at 06:01, Jim J. Jewett
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@gmail.com | Brisbane, Australia