[Python-Dev] A usability argument for list-after-def (original) (raw)

IxokaI ixokai at gmail.com
Fri Aug 6 00:00:24 CEST 2004

For what its worth, this lurker until now is strongly +1 on list-after-def, regardless of how it turns out. Real list, fake list, pseudo-keyword seperator.

I don't like @syntax because unless you're using whitespace between def's in the 'right' way its just.. not completely clear what belongs to what.

class incdec: def increment (arg): return arg +1 increment = staticmethod(increment) @staticmethod def decrement(arg): return arg - 1

That looks like a mess. Python uses whitespace to group things, and @syntax is not in any way grouped or connected to the function.. No, its not ambigious, its just-- messy, unclear to a novice.

However:

class incdec: def increment(arg) [staticmethod]: return arg +1 def decrement(arg) using [staticmethod]: return arg -1

clearly shows that the decorator is decorating that specific function. You may not know just what its doing, but you know its directly related. I think that's very important.

--Stephen

On Thu, 5 Aug 2004 23:52:26 +0200, Gregory Lielens <gregory.lielens at fft.be> wrote:

> Of the options on the Wiki page ( at > http://www.python.org/moin/PythonDecorators ), this seems to > leave only > list-after-def, the previous community favorite and the first PEP 318 > syntax to have been implemented. > > Guido's principal argument against list-after-def, if I > recall correctly, > was that it is ugly when multiple or lengthy decorators are > involved. But, > "ugly" isn't an argument any more, so that shouldn't rule out > list-after-def. :) On a cosmetic point of view, I also prefer the list-after-def syntax, first time I saw it it was the one than seemed the easiest (the "def f() as [decorator]" variant was event clearer, but the argument that as is only for renaming has mitigaed that somewhat ;-) ) "Cosmetic" does not sound like a very convincing argument, but I feel that this whole discussion is purely on a cosmetic level anyway, it is just a way to express more clearly something that is already possible...and as feedback as been asked for... ;-) But does it means that the list-after-def behaves like all lists, so that these are possible and equivalent? def foo() [decorator1, decorator2(bar)]: ... def foo() [ decorator1, decorator2(bar)]: ... mycomplexdecorator=[decorator1, decorator2(bar)] def foo() mycomplexdecorator : ... If it is, I am +1 on list-after-def (and, because of the last example, +2 on a variant with a keyword or pseudo-keyword between the def and the list, like ("with" is only an example) : def foo() with [decorator1, decorator2(bar)]: ... mycomplexdecorator=[decorator1, decorator2(bar)] def foo() with mycomplexdecorator : ... def foo2() with mycomplexdecorator : ... If not (i.e. the brackets are just a syntax hint), I am -1, I prefer the the pie syntax cause it would break consistency with other lists usage... For example, for j in [1,2]: ... for j in ["a","b", 1,2,3,4]: ... for j in mylist: ... are all possible, so it would be very surprising if the def syntax would not be similar, it would mean that the brackets after a def are not really a list and that would feel too much like special-casing to me... Best regards, Greg.

Python-Dev mailing list Python-Dev at python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/ixokai%40gmail.com

More information about the Python-Dev mailing list