[Python-ideas] Assignment decorators (Re: The Descriptor Protocol...)

Nick Coghlan ncoghlan at gmail.com
Fri Mar 4 10:46:54 CET 2011


On Fri, Mar 4, 2011 at 1:14 PM, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> It actually annoys me quite a lot every time I bump into
> something like this, because the language virtually forces
> a DRY violation on me that's impossible, or at least
> extremely awkward, to avoid.
>
> Python is generally very good at not reserving special
> powers for itself, but this is one area where there is
> a mechanism (for defining a thing that knows its own name)
> that works in certain specific cases (def and class) but
> is not open to the programmer for easy use in a general way.
> That strikes me as a wart.

It's probably worth reminding people of Steven Bethard's attempt at
addressing this issue several years back: PEP 359's "make" statement,
which was specifically about invoking functions of the form f(name,
tuple, namespace) to reduce abuses of class statements for that
purpose.

The language has moved on quite a bit since then (e.g. with the
addition of abstract base classes, the __prepare__ method in the
metaclass protocol and the new instance methods on property objects
allowing them to be constructed in stages), but the basic question of
how to construct arbitrary objects with an "official" name still
doesn't have a great answer.

To hit a few highlights from the thread:
- '=' has its target on the left and the source expression on the
right. Be cautious in proposing it be used any other way.
- 'as' has its target on the right and something indirectly related to
its source on the left. Be cautious in proposing it be used any other
way.
- I agree with Raymond that new syntax needs serious justification
that this discussion hasn't uncovered yet (see [1] from me and [2]
from the C# design team).

Something comparable in power to PEP 359 would get closer to the
threshold needed, since it would eliminate a number of uses of
advanced metaclass hackery in favour of comparatively straightforward
function invocations.

Cheers,
Nick.

[1] http://www.boredomandlaziness.org/2011/02/justifying-python-language-changes.html
[2] http://blogs.msdn.com/b/ericgu/archive/2004/01/12/57985.aspx

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



More information about the Python-ideas mailing list