PEP 318: Can't we all just get along?

[John Roth]

"Kevin Smith" <Kevin.Smith at sas.com> wrote in message
news:20040817181725194-0400 at braeburn.themorgue.org...
> For what it's worth, I wrote the original PEP 318.  I probably wasn't
> qualified, but I just wanted a nice simple way to declare class methods
> without having to repeat the function name.  After submitting it to BDFL
> for approval, more work was needed and the discussion of PEP 318 on
> python-dev increased rapidly.  It was evident that I was in over my head,
> so I asked more someone more experienced to take over.
>
> I guess others had bigger plans for my proposal that I had planned.  It
> has turned into the "solution" to many problems: type checking (both
> arguments and returned values), metaclasses, metadata, interfaces,
> function attributes, etc.).  Unfortunately, in the process, this simple
> request for syntactical sugar has turned into a monstrosity.  In my
> opinion, none of the proposed syntaxes really seem Pythonic.  This PEP
> just seems to be trying to solve too many problems.

I don't think that is the case. What is actually going on has to do
with the mechanics of the classmethod and staticmethod functions.
They wrap the actual function in a special purpose descriptor.

The current approach is simply to allow running any wrapping
function, not just classmethod and staticmethod. That is, in a
very real sense, realistic because if they put in a special purpose
hack for just those two descriptors, then you'd get a huge backlash
from people who will still complain that it doesn't support, for
example, properties.

All the other stuff you're seeing isn't something that the proposal
has to support explicitly. You can wrap a function in any kind
of a descriptor you want. They are simply use cases, and IMHO,
some of them are not very well founded. However, none of them
involves one line of code more or less than the basic "allow
any descriptor anyone cares to write as a wrapper" approach.

The arguement is, and always has been, about syntax. Everyone
agrees that the current situation is not ideal; putting the wrapping
assignment statement after the method is a very poor way of
declaring intent.

In other words, forget the use cases. They're irrelevant. The
sticking point on syntax has to be solved first. If it is, then
I doubt if you're going to get a special purpose, just those
two specific descriptors and no others, solution. I just don't
see it happening.

There is, by the way, one syntax that hasn't to my knowledge
been proposed that is straightforward, natural, doesn't
make it begin to look like line noise and is completely
consistent with existing syntax. Just use the '.' operator
on the name and be done with it. For example:

def classmethod.fubar(self, widget, wadget, boff):
    pass

I'm not seriously proposing it because I'd like to reserve
that idea to be able to insert a method into an instance
or existing class without either having to do an extra
assignment, or having to pollute the module namespace
in passing.

John Roth

>
> -- 
> Kevin Smith
> Kevin.Smith at sas.com