[Python-ideas] Explicit variable capture list

[Andrew Barnert]

On Wednesday, January 20, 2016 11:05 AM, Yury Selivanov <yselivanov.ml at gmail.com> wrote:

> FWIW I strongly believe that this feature (at least the
> "len=len"-like optimizations) should be implemented as an
> optimization in the interpreter.

The problem is that there are two reasonable interpretations for free variables--variable capture or value capture--and Python can only do one or the other automatically.

Python does variable capture, because that's what you usually want.[*] But when you _do_ want value capture, you need some way to signal it. In some cases, the only reason you want value capture is as an optimization, and maybe the optimizer can handle that for you. But sometimes there's a semantic reason you want it--such as the well known case (covered in the official Python Programming FAQ [1]) where you're trying to capture the separate values of an iteration variable in a bunch of separate functions defined in the loop. And we need some way to spell that.

Of course we already have a way to spell that, the `a=a` default value trick. And I personally think that's good enough. But if the community disagrees, and we come up with a new syntax, I don't see why we should stop people from also using that new syntaxfor the optimization case when they know they want it.[**]

  [*] Note that in C++, which people keep referring to, the Core Guidelines suggest using variable capture by default. And their main exception--use value capture when you need to keep something around beyond the lifetime of its original scope, because otherwise you'd get a dangling reference to a destroyed object--doesn't apply to Python.

  [**] I don't think people are abusing the default-value trick for optimization--I generally only see `len=len` in low-level library code that may end up getting used inside an inner loop--so I doubt they'd abuse any new syntax for the same thing.


  [1] https://docs.python.org/3/faq/programming.html#why-do-lambdas-defined-in-a-loop-with-different-values-all-return-the-same-result

> We already have "nonlocal" and "global".  Having a third
> modifier (such as sharedlocal, static, etc) will only
> introduce confusion and make Python less comprehensible.


I agree with that. Also, none of the names people are proposing make much sense. "static" looks like a function-level static in C and its descendants, but does something completely different. "capture" means the exact opposite of what it says, and "sharedlocal" sounds like it's going to be "more shared" than the default for free variables when it's actually less shared.