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