[Python-ideas] Assignments in list/generator expressions

[Nick Coghlan]

On Tue, Apr 12, 2011 at 4:51 PM, Eric Snow <ericsnowcurrently at gmail.com> wrote:
> I know this throws off the approach the PEP takes, but I am trying to wrap
> my head around how I would use statement local namespaces.  I like how it
> cleans up from the namespace those bits that only matter to the target
> statement.  It does make it easier to follow to whom those statements in the
> given block belong.

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

Dropping the second suite (and having the given clause implicit modify
the following statement) isn't really feasible (and far more brain
bending than adding a new clause to augment simple statements).

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 I had to come up with a concise rationale for when you would use
them (with the post-fix syntax and anonymous function semantics
proposed in the PEP):

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)

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.

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

4. You want to enable function-level optimisations in module or class level code

1 and 2 are the core of the rationale for even proposing the idea of
statement local namespaces in the first place, but come with the
downside of making it harder to test your setup code. 3 is one of the
aspects of my most proposed implementation strategy that I most like
(since the default-argument hack is a genuinely ugly wart). 4 is just
a perk of my proposed implementation strategy rather than a compelling
use case in its own right.

Cheers,
Nick.

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