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

[Paul Morrow]

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. 
> 

Nope.  That's using static declarations.  We're a dynamically typed 
language as much as possible.  Isn't there something that doesn't 
require any additional grammar words to identify classmethods and 
staticmethods?  Isn't there something, inherent in the way static, 
class, and instance methods 'look' naturally, that would tell us what 
they are?