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

[Guido van Rossum]

Greg, what is your use case for passing the lhs name into the
function? Because that seems to be your purpose.

Also it seems that one couldn't decorate all but the simplest assignments:

@dec
lhs = rhs
# lhs = dec('lhs', rhs)

@dec
lhs.attr = rhs
# lhs.attr = dec('lhs.attr', rhs)  ???

@dec
lhs[i] = rhs
# lhs[i] = dec('??????', rhs)

@dec
lhs1, lhs2, lhs3 = rhs
# lhs1, lhs2, lhs3 = dec('???????????', rhs)

The use case I can think of for the first example would be to declare
fields in a model class that know their own field name, as in Django
and AppEngine models, and many other libraries. But that use case is
covered pretty well by metaclasses, and the @decorator syntax has the
disadvantage of requiring at least two lines per field, whereas the
current solution requires only one line (and there is no explicit
repetition of the field name -- the metaclass takes care of it).

--Guido

On Thu, Mar 3, 2011 at 2:40 PM, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> Ethan Furman wrote:
>>
>> Greg Ewing wrote:
>>
>>> I think we should have assignment decorators.
>>>
>>> @decorator
>>> lhs = rhs
>>
>> That seems very verbose -- part of the issue for me is all the extra
>> typing involved in specifying the name twice, and I don't think this is
>> going to save many, if any, keystrokes.
>
> I don't follow. It costs an @ and a newline, but it saves
> one instance of the name, plus two quotes, a comma and
> perhaps a space.
>
> Anyway, the main issue for me in violating DRY isn't the
> number of keystrokes. The main issues are:
>
> * It's harder to read -- the repeated name is just noise
>  that doesn't convey any useful information to the reader.
>
> * It's harder to maintain -- if you change the name, you
>  have to remember to change it in both places.
>
> --
> Greg
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>



-- 
--Guido van Rossum (python.org/~guido)