[Python-Dev] Re: new syntax for wrapping (PEP 318)

[Thomas Heller]

"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