-
Can you use decorators with something besides functions? Lie:
class Foo:
. @readonly
. bar = 10
Where bar is replaced with some descriptor (whatever readonly(10) returns?)
-
By no means am I an expert in Python (I get paid for writing Java, although my hobby projects have been in Lisp over the past few years), but this @decorator flap has made no sense to me at all.
The best argument against the new syntax is that it will impede noobs (like myself, I suppose) from picking up the language. I think nothing could be further from the truth, for one reason: action-at-a-distance is *always* bad.
The first time I saw this, I almost fell out of my chair:
def blah (args):
....[insert 50/100/200 lines here]
blah = staticmethod(blah)
That's BAD. That, my friends, is tough to wrap one's mind around, for the exact reason that, unless one reads through an entire module, the critical staticmethod call might not even be seen. That's a pretty devestating blow to the ability of a noob (or hell, anyone for that matter) to learn what's going on in some code.
So, when I see:
@staticmethod
def blah (args):
....[insert 100 lines]
I say, YES! Sure, decorators can get complicated, as exemplified by some of the examples provided in the post. However, just because something is complicated, or even not the greatest approach in some cases, doesn't invalidate it. Take recursion: a concept and practice that noobs trip over almost as a rule, and an approach that is constantly abused and overused in inappropriate situations. However, that surely doesn't mean that recursion should be disallowed, or scorned even. It means it should be respected, taught well, and used when appropriate. Decorators surely fall into the same category.
-
""" Can you use decorators with something besides functions?"""
Apparently you get a SyntaxError if you try that...
-
And Python takes two more steps towards Lisp ... http://tmp.i.am/2004/08/14.html
-
Hmm. I have to say that the "@" feels, to me, vaguely Perl-ish... in that "what symbol have we not yet used that we can overload to add this new context" sorta way.
I'm with Hans on this; nobody's yet posted (that I have seen) a convincing use-case for decorators that warrants their building-in to the language. You can already *do* all the decorating, albeit with a more complex syntax, but if you're programming at a level that needs decorators, you're almost certainly competent to write the code yourself. I'd rather see a "decorator" modules than a dedicated syntax.
Ho hum :)
b
-
Very interesting. Now if Python would only let me inspect the function definition, I could do all kinds of wonderful magical things. For example, I'm currently trying to figure out how to make Python do dataflow (a.k.a. spreadsheet-style evaluation) without abusing the language syntax too horribly much. My main problem is that while Python makes it easy to overload expressions, it's impossible to overload statements. See http://www.kimbly.com/blog/000363.html
The problem is that I have to do things like replace if-statements with calls to an _if function. That means you lose the indentation-based layout, and it looks horrible.
But if I could take a function and inspect it programmatically, then I could construct a new function definition that does what I need, even though it would look exceedingly ugly if you were to write it out by hand.
Lisp macros indeed...
-
Oooh, I just found the "inspect" module, which lets you get at the source code for functions. It's a lot flimsier than what I'd like (I'd prefer a parsed AST), and it only works if you have source code available, but it's better than nothing...
-
Sorry for thinking out loud here, but now I've found the "parser" module. This is great! :) I now have pretty much everything I need to be able to do dataflow semantics for functions. It won't be able to handle arbitrary callable objects, since it won't in general be possible to get at their source code, but functions are a good start.
-
I took your examples and translated them to Ruby (before I hacked the Ruby interpreter ;-):
http://www.ntecs.de/blog/Blog/PythonDecorators2.rdoc
http://www.ntecs.de/blog/Blog/PythonDecorators.rdoc
Please don't take this as a flame war.
-
Not nice, but short and concise:
class C(object):
. @property
. def foo(self):
. . #do computations
. . return something
This is useful for rapid-propotyping, when you have to use properties (instead of methods) because you plan to add an fset function to the property later.