"Phillip J. Eby" <pje@telecommunity.com> writes:
Thomas Heller wrote:
For me, the advantage of the current
def foo(cls): ... foo = classmethod(foo)
is that it *exactly* describes what's going on. The difficulty, I would guess, to people coming from other languages, is that they are more used to (how can I explain it) a mental model where a compiler parses some syntax and generates code from that. In python, it *is* simply executable code, and it is executed.
What you say is true, but it's also true that assembly code describes *exactly* what is going on. :)
I consider a language cool where I can really, really understand what's going on. Well, mostly ;-), I still wouldn't say this from Objects/typeobject.c.
But I think there needs to be a distinction betweeen "how" something happens, and "what" is happening. For teaching purposes, it's much easier to say, "if you want to make it a class method, put '[classmethod]' here", than it is to explain the existing technique.
If I want to teach someone *how* decorators work (so they can write their own), there is nothing stopping me from demonstrating the foo = classmethod(foo) version.
So, there are two separate issues here. One is *using* decorators, the other is *making* them. I do not need to understand how decorators in general work in order to use them, any more than I need to understand metaclasses to use classes, even though every time I make a class I'm using a metaclass! I only need to know what the particular decorator I'm using (or that someone else used) is supposed to *do* for me. But if I want to *make* a decorator, I need to know how they work. (Personally, I'd look at the source of other decorators to figure that out, but I digress.)
Anyway, the 'foo = classmethod(foo)' thing is actually *noise* when it comes to teaching, because now you have to explain why you're calling a function on a function and assigning it to the same name as an existing function. We've just digressed into functional programming and the Python namespace mechanisms when all we wanted was to talk about class methods! A syntax that goes in the 'def' block is less distracting, because it just becomes part of the "how to define a class method" rather than opening up all these other issues.
This sort of "put the language in the background and the task in the foreground" thing is Python's traditional strength, and I believe that having a reasonable decorator syntax that takes place as part of the 'def' statement will allow that strength to apply to classmethods, staticmethods, and numerous other types of function decorators.
All this is more or less what I wanted to express. Although I would consider this def func() [__main__]: ... as an ugly hack - it tries to hide what's going. But any advanced feature can be abused, probably. Thomas