On 27/03/2018 16:22, Guido van Rossum wrote:
On Tue, Mar 27, 2018 at 7:00 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:
On 27 March 2018 at 01:57, Guido van Rossum <guido@python.org> wrote:
> On Mon, Mar 26, 2018 at 7:57 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:
>> By contrast, the sublocals idea strives to keep the *lifecycle* impact
>> of naming a subexpression as negligible as possible - while a named
>> subexpression might live a little longer than it used to as an
>> anonymous subexpression (or substantially longer in the case of
>> compound statement headers), it still wouldn't survive past the end of
>> the statement where it appeared.
>
>
> But this is not new: if you use a for-loop to initialize some class-level
> structure  you have the same problem. There is also a standard solution
> (just 'del' it).

Right, but that's annoying, too, and adds "Am I polluting a namespace
I care about?" to something that would ideally be a purely statement
local consideration (and currently is for comprehensions and generator
expressions).

The standard reply here is that if you can't tell at a glance whether that's the case, your code is too complex. The Zen of Python says "Namespaces are one honking great idea -- let's do more of those!" and in this case that means refactor into smaller namespaces, i.e. functions/methods.

This is not always satisfactory.  If your for-loop uses 20 already-defined-locals, do you want to refactor it into a function with 20 parameters?
Regards
Rob Cliffe