[regularfry]

Class methods needing decorators really bugs me too. The problem goes back to explicit self. The explicit self, as currently implemented, carries no information: yes, you get to pick "self" as the instance name, but everyone picks "self" for that and There's One Way To Do It in Python anyway. If you could declare a class method like this:

    class Foo(object):
      def class_method(Foo):
        pass

then suddenly explicit self gains a meaning (Hey! Instance method!) and class method declaration doesn't go through a completely unrelated mechanism.

>> methods only become class methods when a decorator is used

> That's because the decorator is basically a flag to tell the attribute-resolution process to handle this method differently from the normal method-resolution process.

Do you see how that's just special-casing method declaration in a similar way to Ruby's mechanism, just relying on the programmer to drive the mechanism himself? To a not-so-casual observer it looks like Guido wasn't willing or able to change enough semantics to make a syntactic fix work for class method declaration, despite there being an obvious space in the syntax for it to fit in, so lent on a convenient implementation detail - a hack - to get the same effect with more work for the programmer.

Of course, it's equally possible that he believes that class methods are a code smell and should be explicitly made ugly, which I could have a certain sympathy for, but to me the current situation just looks really inelegant.

[masklinn]

> yes, you get to pick "self" as the instance name, but everyone picks "self" for that

No, actually, there have been situations in the past where using `self` was not the best choice, and I didn't. Using `self` is extremely confusing when defining methods on metaclasses for instance (self turns out to be a class object)

> If you could declare a class method like this:

You completely change the semantics of defining methods and potentially break explicit code.

> Do you see how that's just special-casing method declaration in a similar way to Ruby's mechanism, just relying on the programmer to drive the mechanism himself?

The programmer is always the driver, the difference is that decorators allow doing this without adding a pointless syntactic special case.

[regularfry]

> No, actually, there have been situations in the past where using `self` was not the best choice, and I didn't. Using `self` is extremely confusing when defining methods on metaclasses for instance (self turns out to be a class object)

Here's somewhere that Python could have made things easier for you. What's wrong with `self` being a class object? It's something Ruby gets right, in my opinion.

> You completely change the semantics of defining methods and potentially break explicit code.

Yep. In a good way. Guido had a chance to fix this at Python 3, and didn't. Do you seriously not see the benefits of the code I posted?

> The programmer is always the driver, the difference is that decorators allow doing this without adding a pointless syntactic special case.

Yes, the programmer's always the driver, but my point is that in Python the programmer has more driving to do than necessary. The reason this is confusing and inelegant is precisely because it's not a pointless case. Decorators allow doing it, but they're absolutely not the best way, its a (ab)use of a conceptually unrelated mechanic.