[Python-ideas] Assignments in list/generator expressions

[Nick Coghlan]

On Tue, Apr 12, 2011 at 12:57 AM, Guido van Rossum <guido at python.org> wrote:
>> pass given: # I'll add "pass" to the list of supported statements in PEP 3150
>>    for opcode in opname:
>>        if not opcode.startswith('<'):
>>            class O(Opcode):
>>                pass
>>            opcode = opcode.replace('+', '_')
>>            O.__name__ = opcode
>>            globals()[opcode] = O
>>
>> There's also a performance hack in there: "given:" drops you down into
>> a function scope, so you get the benefits of function local
>> performance.
>
> Can't say I like this one. "pass given" sounds icky (and I think
> earlier in this thread someone flagged it as undesirable).

It isn't on the list currently in the PEP, as the only ones I included
there were the simple statements that permitted the use of
subexpressions.

However, if "pass" is left *off* the list, then the moral equivalent
of "pass given:" could still be written in a variety of other ways,
such as:

0 given: # Somewhat counterintuitive due to "if 0:"!
  pass
1 given:
  pass
"pass" given:
  pass
... given:
  pass

I figure I may as well bite the bullet and include "pass" as an
obvious way of doing inline code in a private scope.

> I think that "given" will particularly shine in code written in a
> "top-down" programming style, where one first presents the high-level
> outcome and pushes details to the back. This can currently be done
> quite well by putting the "main()" function definition first and then
> developing it from there, but there is a certain elegance in having
> the helper functions not exposed at the module level. (Although I can
> also see that people who really like this style will overuse it and
> put everything in a big sprawling deeply-nested structure, as opposed
> to making the helpers all siblings. And it won't increase
> testability.)

Yeah, being able to reach in and explicitly test "_" prefixed helpers
is very handy in writing good white box test suites. My own feelings
on PEP 3150 still sit around the level of finding it interesting and
potentially valuable as a concept (otherwise I wouldn't have written
the PEP in the first place!), but I'm not yet convinced that its net
impact on the language would be positive. My main stumbling block is
the fact I still can't characterise suitably obvious criteria as to
when it should be used over normal imperative code. I'd be a lot
happier with the PEP if I could include a specific proposal for PEP 8
additions regarding its applicability.

Cheers,
Nick.

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