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

[Phillip J. Eby]

At 08:27 PM 2/26/04 +0100, Thomas Heller wrote:
>Christian Tismer <tismer at stackless.com> writes:
>
> > Thomas Heller wrote:
> >
> >> The above code looks like as someone forgot to actually initialize the
> >> class variable (probably not too likely with the name 'classmethod', but
> >> with other names):
> >> class klass:
> >>    classmethod = 42
> >>    def foo():...
> >
> > Yes I know. I just wanted to encourage people to think
> > of simpler alternatives but to spoil the language
> > for tiny improvements.
> > I didn't just want to say "this is ugly", but to think of
> > ways to express "the following is meant to be a... method".
> >
> > Onw thing I could live with if I must is "class method",
> > since it is similar to other languages.
> >
> > reminds-me-of-ternary-operators -- chris
>
>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.  :)

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.