Alternative decorator syntax - POLL RESULTS SO FAR - ARE WE DONE?

Michael Sparks zathras at
Sun Aug 22 15:37:24 CEST 2004

Peter Hansen wrote:
> Although I'm not sure it was implemented this way, I
> believe there may be an intent to support the usual
> sort of one-line version as this (using an alternate
> keyword instead of "decorate" which now seems doomed):
>      using: staticmethod
>      def foo(bar, baz):
>          pass
> That makes it no extra lines, but still explicit and Pythonic
> in nature.
> (Michael, was that how you implemented the latest?)

I'm certainly intending to have this short form. However first of all I'm
working through producing a full patch based on Anthony Baxter's pointer,
to the original patch.

When I do add the short form, it's most likely to include the replacement
"using" keyword. The impact of "decorate" and "declare" on user code looks
too large for comfort. (Well known projects broken by one or the other
include mailman and Pyrex)

Interestingly though the form as implemented does already allow for:

   staticmethod synchronised deprecated
def foo(baz):

Largely because the current 2.4a2 form allows for:

@staticmethod @synchronised @deprecated
def foo(baz):

Both of which strike me generally speaking as nicer than the long list
approach. Once I've made the change I intend to make (assuming it's simple
enough) I'll make the simple/short form allow (assuming possible):

using: staticmethod synchronized deprecated memoize
def foo(baz):

Mark Russell did a real a really nice job on the original implementation,
and when this is all over that's where the real thanks are due!



More information about the Python-list mailing list