Poll - Vote here for "list-after-def" (was Decorator syntax)

[Peter Hansen]

Istvan Albert wrote:

> Paul McGuire wrote:
> 
>  > Please reconsider the "def f() [classmethod]:" construct.  
>  >
>  > def f() [ staticmethod,
>  >     synchronized,
>  >     alphabetized,
>  >     supersized,
>  >     returns('d') ]:

Nobody has bothered to post an example with a long argument list,
thus ignoring the possibly valid claim in the PEP that this would
make the decorator list hard to see.  Here goes:

     def someMethod(self, posArgOne, anotherArg,
         fieldX=56,
         x=5, y=7, z=9,
         **kwargs)
         [
         staticmethod,
         synchronized,
         alphabetized,
         supersized,
         returns('d')
         ]:

Okay, pretty much an abomination, but I'm not sure it's any worse than
the alternative with @:

     @staticmethod
     @synchronized
     @alphabetized
     @supersized
     @returns('d')
     def someMethod(self, posArgOne, anotherArg,
         fieldX=56,
         x=5, y=7, z=9,
         **kwargs):

It *is*, however, fairly clear that the list of decorators becomes
harder to see.  Without checking, it's definitely possible that the
decorator list in the first case is actually part of the argument list.

I don't care.  I still prefer it to @, if nothing else because
it's much more intuitive to a Python programmer what order they
will be applied in.

> Voting for the "list-after-def" syntax as shown above:

Apparently the term "voting" is deprecated when related to PEPs
and language design.  ;-)  Instead, we should now be using the term
"expressing their opinion in favour of"...

At least, I hope we are still allowed to express opinions in favour
of things...

-Peter