[Python-ideas] Explicit variable capture list

Nick Coghlan ncoghlan at gmail.com
Sun Jan 24 07:54:53 EST 2016


On 24 January 2016 at 15:16, Guido van Rossum <guido at python.org> wrote:
> I wonder if kids today aren't too much in love with local function
> definitions. :-) There's a reason why executor.submit() takes a
> function *and arguments*. If you move the function out of the for loop
> and pass the url as a parameter to submit(), problem solved, and you
> waste fewer resources on function objects and cells to hold nonlocals.

Aye, that's how the current example code in the docs handles it -
there's an up front definition of the page loading function, and then
the submission to the executor is with a dict comprehension.

The only thing "wrong" with it is that when reading the code, the
potentially single-use function is introduced first without any
context, and it's only later that you get to see what it's for.

> A generation ago most people would have naturally used such a solution
> (since most languages didn't support the alternative :-).

In programming we would have, but I don't think the same is true when
writing work instructions for other people to follow - for those,
we're more likely to use nested bullets to describe subtasks, and only
pull them out to a separate document or section if we need to
reference the same subtask from multiple places.

While my view is admittedly only based on intuition rather than hard
data, it seems to me that when folks are reaching for nested
functions, it's that "subtask as a nested bulleted list" idiom they're
aiming to express, and Python is otherwise so accommodating of English
structural idioms that it's jarring when it doesn't work properly. (I
also suspect that's why it's a question we keep returning to - as a
*programming language*, making closures play more nicely with
iteration variables doesn't add any real power to Python, but as
*executable pseudo-code*, it makes it a little bit easier to express
certain ideas in the same way we'd describe them to another person).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia


More information about the Python-ideas mailing list