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

[Jim Fulton]

Bob Ippolito wrote:
> 
> 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've never seen anything but classmethod, staticmethod, property
and my own "contextmethod" and "cachedproperty", both of which are
better served by the simple syntax, in the "wild".   The simple
syntax serves these uses (yes, excluding  write properties) very well.
I certainly *will* use synchronized the the future (I've used something
like it in the past.)

 > I don't think proposals such as this do very
> much for anyone. 

Oh come on.  It does a lot for me.  IMO, it does a lot for future
users of the language by keeping it simpler.  Saying that a proposal
you don't agree with doesn't do much for anyone is unfair IMO.  I
think it's pretty inappropriate to devalue arguments just because
you don't agree with them.

 > It's too simple to be useful, and has too many
> side-effects on existing tools and people that try and read python 
> source :)

Please.  Any syntax will have effects on existing source and users.
IMO, this *obvious* syntax best serves the original purpose of the
PEP, which is to solve the *simple* problem if making the syntax
of class and static methods sane.

> Is @syntax really SO horrible that you propose that we make decorators 
> near useless to most but more "aesthetically pleasing" to some? 

IMO, yes, although I'd happily accept both syntaxes. I can live with
@foo to server the people who want it, but it bugs me that I have to
write:

   @clasmethod
   def foo ....

rather than the, to me, much more obvious and readable:

   def classmethod foo ...

 > Do you
> use a significant amount of decorators now? 

I use class methods and static methods. I use properties a lot,
including lots of read properties. I have my own kinds of decorators
as well, as mentioned above.

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

Well, I use this sort of thing a lot. Most of my uses are served by the simpler
syntax.  For the uses that aren't served by the simpler syntax, the @foo syntax
either doesn't help, as in properties and variations on properties, or doesn't
add anything.

Jim

-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org