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

Paul Morrow pm_mon at
Wed Aug 18 03:13:47 CEST 2004

Peter Hansen wrote:

> Paul Morrow wrote:
>> Kevin Smith wrote:
>>> 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.  
>> 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?  
> It looks to me as though Kevin is not suggesting keywords, but
> callables.  In other words he would consider this valid, provided
> my_own_decorator was a callable.
>   def my_own_decorator foo(x, y, z):
>      pass
> -Peter

Oh, sorry, I wasn't reading that closely enough.  Hmmmm... it's an 
interesting idea.  It's not ugly...

First though, I still believe that we should exploit existing 
conventions (recommended coding practices) as a way of getting 'free' 
declarations for class, static, and instance methods (e.g. methods whose 
first param is 'self' are instance methods, etc.). That feels very 
pythonic to me, just as we use naming conventions to distinguish public, 
private, and semi-private methods.

But I think that, where we want to provide additional info about a 
method, and there are no conventions to take advantage of, Kevin's 
suggestion does have some appeal.

Questions (for Kevin):

1. Would

       def deco1 foo(a, b, c): pass

    be the same as (just syntactic sugar for)

       def foo(a, b, c): pass
       foo = deco1(foo)

    or would it mean something else?

2. Would

       def deco1 deco2 foo(a, b, c): pass

    be the same as

       def foo(a, b, c): pass
       foo = deco1(deco2(foo))


       def foo(a, b, c): pass
       foo = deco2(deco1(foo))

3. Would there be any restrictions on what a decorator could *do* to the 
method it was passed?  e.g. Could it change:

   * the method's name (which could of course affect the method's
     visibility: public|private|semi-private)?
   * whether the method was a static, class, or instance method?
   * the method's signature (formal parameter names, parameter order,
     defaults values)?

More information about the Python-list mailing list