[Python-Dev] Another approach to decorators.
bac at OCF.Berkeley.EDU
Wed Aug 11 23:03:11 CEST 2004
Michel Pelletier wrote:
>>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".
>>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():
>>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...):
> def static2(blah...):
> 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.
More information about the Python-Dev