[Python-ideas] Assignments in list/generator expressions

[Eric Snow]

On Tue, Apr 12, 2011 at 11:53 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:

> 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.
>
>
Overall I like it.  The idea of limiting to assignment is a good one.  This
gives room for custom namespaces without all the class machinery.  It is
certainly something I have seen brought up on several occasions here.  And
these namespaces would not be anonymous since they are tied to the
assignment.  One benefit is that we could deprecate module variables using
this syntax.

-eric


> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20110413/6f04e520/attachment.html>