[Python-Dev] Another approach to decorators. (original) (raw)

Brett C. bac at OCF.Berkeley.EDU
Wed Aug 11 23:03:11 CEST 2004

Michel Pelletier wrote:

Message: 2 Date: Tue, 10 Aug 2004 12:55:19 -0400 From: Martin Zarate <mzarate at uoguelph.ca> Subject: [Python-Dev] Another approach to decorators. To: python-dev at python.org Message-ID: <1092156919.4118fdf7b71c4 at webmail.uoguelph.ca> Content-Type: text/plain; charset=ISO-8859-1

@ means nothing to an uninformed eye. This violates the most important feature of Python (imho) which is that it is "runnable pseudocode". Yes! I submit that the most Python solution, that would also be legible (but not necessarily very pretty) would be to actually make the decorator a bona-fide block that you nest your class or function into. remake functor(foo, bar), staticmethod: def baz(): pass This concretely shows the relationship of the original define statement to its wrapper objects. The principle is simple - the remake block will close with only one object in its immediate namespace I like your idea a lot, buy why just one? Your scheme of making decorators a block could be applied to several methods in a class: class Foo: decorate static: def static1(blah...): pass def static2(blah...): pass To me, this idea looks more like Python than all the rest, and allows you to consolidate related decorated methods and classes. Nest them to apply decorators "aquisition style":

But then how are you supposed to do multiple decorators for the same method?

I am with Martin that a keyword argument is not going to work here. Going that route leads to public static painInTheAssAndClutteredSyntax(That can) implements Lots, Of, Stuff, That throws Things, You, Can, Learn, From, The, Docs hell.

-Brett

More information about the Python-Dev mailing list