[Python-ideas] Assignments in list/generator expressions

Jim Jewett jimjjewett at gmail.com
Tue Apr 12 19:25:23 CEST 2011


On 4/12/11, Nick Coghlan <ncoghlan at gmail.com> wrote:

> Yeah, in order variants have been part of the discussion since the
> beginning, usually in a 2-suite form like:

> let:
>    # local namespace
> in:
>   # binding here affect surrounding scope
>   # but can also see names bound in "let" clause

...
> I really don't see much point to the in-order variants, hence why
> discussing them is currently a TO-DO note in the PEP rather than a
> fully fleshed out description of the problems I have with them.

If you're using two blocks (like the if statement), then why do they
have to be in order?

    exec:  # or "do" or "run" or ...
        ... # ordinary suite
    given:
        ... # suite limited to name bindings statements?  normal suite?

> 1. You wish to avoid polluting the current namespace with working
> variables and helper functions (most relevant for module and class
> level code, but may also be relevant for functions in some closure
> related contexts)

The idea of a throw-away internal class does solve this, but I admit
it looks very odd -- to the point that I would be looking for a
keyword other than class.

> 2. You wish to provide greater prominence to the final statement in a
> series of operations, making it clear to the reader that the other
> statements are mere setup for that final step. This is similar to the
> principle of decorators, where the important information is the
> function name, parameters, annotations and applied decorators, while
> the precise implementation details will be uninteresting for many
> readers.

The reverse-order double suite solves this, so long as you keep the
suites reasonably sized.

> 3. You want early binding for closure references without resorting to
> the default argument hack (including early binding of module globals
> and class variables)

Much as I like this, it sort of requires that the whole function be
wrapped in a
do ... given, which might start to look like pointless boilerplate if
people start to do it too often.

-jJ



More information about the Python-ideas mailing list