Home Original page

[Python-ideas] PEP 563: Postponed Evaluation of Annotations, first draft

Nick Coghlan ncoghlan at gmail.com
Tue Sep 12 07:17:23 EDT 2017 
On 12 September 2017 at 11:45, Steven D'Aprano <steve at pearwood.info> wrote:
>> Rejected Ideas
>> ==============
>>
>> Keep the ability to use local state when defining annotations
>> -------------------------------------------------------------
>>
>> With postponed evaluation, this is impossible for function locals.
>
> Impossible seems a bit strong. Can you elaborate?

I actually agree with this, and I think there's an alternative to
string evaluation that would solve the "figure out the right globals()
& locals() references" problem in a more elegant way: instead of using
strings, implicitly compile the annotations as "lambda: <expr>". You'd
still lose the ability to access class locals (except by their
qualified name), but you'd be able to access function locals just
fine, since the lambda expression would implicitly generate the
necessary closure cells to keep the relevant local variables alive
following the termination of the outer function.

Unfortunately, this idea has the downside that for trivial
annotations, defining a lambda expression is likely to be *slower*
than evaluating the expression, whereas referencing a string constant
is faster:

$ python -m perf timeit "int"
.....................
Mean +- std dev: 27.7 ns +- 1.8 ns

$ python -m perf timeit "lambda: int"
.....................
Mean +- std dev: 66.0 ns +- 1.7 ns

$ python -m perf timeit "'int'"
.....................
Mean +- std dev: 7.97 ns +- 0.32 ns

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
More information about the Python-ideas mailing list