"Phillip J. Eby" <pje at 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
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