On Aug 4, 2004, at 11:00 AM, Jim Fulton wrote:
Bob Ippolito wrote: ...
Your proposal would make decorators nearly as bad as the current pre-2.4 situation. This is REALLY ugly: foo = decorator(....) @foo def fun(....): ...
I agree, that's really ugly. I wasn't proposing that.
I proposed not allowing decorator arguments. Without decorator arguments, a much simpler syntax can be used, as in:
def classmethod foo(...): ...
Or, alternatively, I'm proposing allowing the above simpler syntax when arguments are not needed and allowing the pie syntax to handle more complex cases.
The original motivation for decirators was to deal with things like properties and specialized methods. I'd like to see these cases handled well. I think these are going to be the most common cases and the cases that new Python programmers are most likely to come accross.
Adding even more syntax sounds like a horrible idea (along with the fact that this particular syntax is hard to syntax highlight, will really confuse lots of existing tools, etc.). I also don't agree that those are the most common cases. I certainly haven't seen a whole lot of staticmethod/classmethod usage, and property is only useful for writing getters (with decorator syntax), so I don't think that will be used very often either. I think that decorators will be used about 98% for domain specific purposes with non-standard decorators and 2% will be uses of decorators that come in the standard library such as staticmethod, classmethod, and property (for writing getters). Anyway, it's probably too late to change anyone's mind. Decorators are in @as-is, and I don't think anything you can say now is going to change that. -bob