[Python-ideas] Explicit variable capture list

[Brett Cannon]

On Sun, Jan 24, 2016, 04:55 Nick Coghlan <ncoghlan at gmail.com> wrote:

> 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.
>

So the doics just need an added comment to help explain it. Want to file an
issue for that?



> > 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).
>

I personally like the semantics we currently have. I get why people bring
this up, but I'm voting for the programming language side over the
pseudo-code angle.

-Brett



> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20160124/21f017ea/attachment.html>