Rather than decorators, how about sections?
pm_mon at yahoo.com
Wed Aug 11 21:34:44 CEST 2004
Christophe Cavalaria wrote:
> Paul Morrow wrote:
>>> 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
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 :
>>>> print "Hi, I'm function f"
>>>> doIt = f
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