Steven Bethard wrote:
> My only (mild) concern is that if staticmethod is going to get a
> __call__, I think classmethod should probably get one too. Inside a
> class this doesn't make much sense:
I agree, make sense or not, if "@staticmethod def foo()" and a simple
"def foo(self)" can all be called inside class definition, "@classmethod
def foo(cls)" should too.
> Anyway, my feeling was that running into this behavior (that
> staticmethod is not callable) is a good oportunity to explain how
> descriptors work. And once you start playing around with staticmethod
> and classmethod, you're going to need to learn that pretty soon
> anyway. Hiding it a little bit longer with a __call__ method on
> staticmethod isn't going to help much in the long run.
The problem is that even after explaining descriptors (which IMHO can be
a more advanced feature for newbies), you still need a workaround and
you might end up with (or call __get__):
class A:
def foo(): pass
bar = foo()
foo = staticmethod(foo)
Which I find sad considering all the energy debating @decorators;)
Regards,
Nicolas
_______________________________________________
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
