PEP 318

[David M. Wilson]

Ville Vainio <ville at spammers.com> wrote...

> The current foo=staticmethod(foo) makes the Python 'staticmethod' seem
> like a hack. Many users of staticmethod won't even need to know that
> wrapping takes place.

I find myself in diametric opposition here. :)

Users (read: developers) /should/ know how staticmethod is working
under it's skin, that's (and hopefully no-one here disagrees) a bloody
good thing. The fact that defining a static method is a simple
assignment tells the developer a lot more about Python's internal
workings than extra syntax does. It's far more general, it's explicit,
and it's readable.

I can't see at all how it can be considered a hack.

If at some future date, staticmethod becomes intrinsicly linked to the
Python core in some magical way, then I can see an argument for extra
syntax, but as it stands, staticmethod is a wrapper, defining a
staticmethod is equivalent to "foo = staticmethod(foo)", and "def foo
as staticmethod" is in my books rather ambiguous.


>  It certainly discourages people from using the
> feature in the first place.

Again, I can't see how.


> And when did syntactic beauty stop mattering?

Don't get me wrong, I love lovely looking code, but I don't like code
that wears makeup, which is what this is. We can already do this via
another, simple, more descriptive means.


David.