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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4