[Python-Dev] A usability argument for list-after-def

[IxokaI]

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)]:
>    ...
> 
> my_complex_decorator=[decorator1, decorator2(bar)]
> def foo() my_complex_decorator :
>    ...
> 
> 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)]:
>    ...
> my_complex_decorator=[decorator1, decorator2(bar)]
> def foo() with my_complex_decorator :
>    ...
> def foo2() with my_complex_decorator :
>    ...
> 
> 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
>