Rather than decorators, how about sections?

Paul Morrow pm_mon at yahoo.com
Wed Aug 11 21:34:44 CEST 2004


Christophe Cavalaria wrote:

> Paul Morrow wrote:
> 
> 
>>>class Foo(object):
>>>    def spam(Foo):
>>>        print "Class Method"
> 
> 
> What is that ? It's ugly, it's a name alias and it'll be incredibly
> confusing when classmethods are inherited, which is exactly the most common
> use case for classmethods.
> 

Fine, instead of Foo (the name of the class), use the word klass.  It's 
a popular name for the first parameter of a class method.

> 
>>I like it!  It's simple, clear, ... Why isn't this the hands-down best
>>solution? Why do we want to be more verbose than necessary?
> 
> 
> It isn't a solution. It only "resolves" the problem for staticmethod and
> classmethod which are only a very small part of what we do/want to do with
> decorators.
> 

What we want to do with decorators, it appears, is to clutter up our 
code with declarations, some of which are just pragmas.  I thought we 
liked dynamic declarations (where it's obvious what's going on, as it 
would be here).

> 
> Well, it might seem strange but :
> - It will break a lot of code which use a name different than self for the
> first argument
> - It'll break all existing classmethods
> - It'll break code that binds arbitrary functions as a member function. You
> can't do things like that anymore :
> 
> 
>>>>def f(s):
>>>>    print "Hi, I'm function f"
>>>>class Klass:
>>>>    doIt = f
>>>>Klass().doIt()
> 
> 

Breaking existing code is not necessarily a bad thing.  If you worry too 
much about it, you end up with a real mess of a language.  One that's 
hard to read/write/understand.

To a junior pythonista, in your example, the way you chose 's' as the 
argument name, f looks like it might be a static method.  It would have 
been more clear to use 'self' instead.

So I think that dropping the decoration syntax for class and static 
methods, and instead requiring that we use a particular naming 
convention for their 1st arguments, we not only improve the readibility 
of our code (less arcane syntax), but the correctness of our reader's 
expectations as well.





More information about the Python-list mailing list