[Python-Dev] PEP 318: Can't we all just get along?

[Bob Ippolito]

On Aug 18, 2004, at 3:42 PM, Kevin Smith wrote:

> 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.
>
> Bear with me, but I'd like to propose one more syntax that is simple, 
> easy for newbies to understand,  and nowhere near as powerful as the 
> current PEP's syntax.  However, it doesn't add incoherent, arbitrary 
> syntax either.
>
> def classmethod foo(x, y, z):
>     pass
>
> That's it.  One "decorator" that is a callable object that takes a 
> method as it's only argument.  No expressions, lists, tuples, etc.  
> Just one callable object.  Ok, if you absolutely must have more than 
> one.
>
> def classmethod synchronized foo(x, y, z):
>     pass
>
> Once again, no expressions.  I know that this isn't going to solve 
> everyone's type-checking, metadata, and function attribute problems, 
> but let's face it, using this PEP for all of those things just creates 
> ugly syntax.  There must be more Pythonic ways to do those things in 
> their own PEPs.

The problem is that there is FAR FAR more use of type-checking, 
metadata, and function attributes in the wild (from what I've seen and 
written) than simple stuff like classmethod, staticmethod, and this 
hypothetical synchronized.  I don't think proposals such as this do 
very much for anyone.  It's too simple to be useful, and has too many 
side-effects on existing tools and people that try and read python 
source :)

Is @syntax really SO horrible that you propose that we make decorators 
near useless to most but more "aesthetically pleasing" to some?  Do you 
use a significant amount of decorators now?  Do you plan to use them 
much in the future?  It seems to me that most people who argue against 
the sensible and flexible syntaxes are the same people who will rarely 
if ever use decorators at all...

-bob