On 12 September 2017 at 11:45, Steven D'Aprano <st...@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 | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
