[Python-ideas] Assignments in list/generator expressions

[Nick Coghlan]

On Wed, Apr 13, 2011 at 2:35 AM, Terry Reedy <tjreedy at udel.edu> wrote:
> On 4/12/2011 4:31 AM, Nick Coghlan wrote:
>
>> 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)
>
> I am puzzled why namespace sanitation fans are so allergic to the namespace
> cleanup statement == 'del'.

For one of the key reasons decorators and context managers exist -
it's hard to audit "at the end" stuff for correctness.

>> 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.
>
> And decorators put the def line *last* instead of first, whereas the
> proposed 'given' moves the punchline statement from last to first.

This whole discussion has been really useful to me in crystallising
*why* I see value in PEP 3150, and it is directly related to the way
function and class definitions work.

I have the glimmerings of a rewrite of PEP 3150 kicking around in my
skull, that may include restricting it to assignment statements (I'm
not 100% decided on that point as yet - I'll make up my mind as the
rest of the rewrite takes shape). The reason I am considering such a
restriction is that the new Rationale section will likely be along the
following lines:

=========================

Function and class statements in Python have a unique property
relative to ordinary assignment statements: to some degree, they are
*declarative*. They present the reader of the code with some critical
information about a name that is about to be defined, before
proceeding on with the details of the actual definition in the
function or class body.

The *name* of the object being declared is the first thing stated
after the keyword. Other important information is also given the
honour of preceding the implementation details:

- decorators (which can greatly affect the behaviour of the created
object, and were placed ahead of even the keyword and name as a matter
of practicality moreso than aesthetics)
- the docstring (on the first line immediately following the header line)
- parameters, default values and annotations for function definitions
- parent classes, metaclass and optionally other details (depending on
the metaclass) for class definitions

This PEP proposes to make a similar declarative style available for
arbitrary assignment operations, by permitting the inclusion of a
"given" suite following any simple (non-augmented) assignment
statement::

    TARGET = [TARGET2 = ... TARGETN =] EXPR given:
        SUITE

By convention, code in the body of the suite should be oriented solely
towards correctly defining the assignment operation carried out in the
header line. The header line operation should also be adequately
descriptive (e.g. through appropriate choices of variable names) to
give a reader a reasonable idea of the purpose of the operation
without reading the body of the suite.

=========================

Another addition I am considering is the idea of allowing the "given"
suite to contain a docstring, thus providing a way to make it easy to
attach a __doc__ attribute to arbitrary targets. This may require
disallowing tuple unpacking and multiple assignment targets when using
the given clause, or else simply raising a syntax error if a docstring
is present for an assignment using either of those forms.

Other use cases will of course still be possible, but that will be the
driving force behind the revised PEP.

Cheers,
Nick.

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