On Wed, Jun 11, 2008 at 12:22 PM, Antoine Pitrou <[EMAIL PROTECTED]> wrote: > Calvin Spealman <ironfroggy <at> socialserve.com> writes: >> >> staticmethod doesn't wrap anything, it just creates a descriptor on >> the class with a __get__ that returns the original, untouched >> callable. Doesn't even care _what_ the thing you use it on is >> (function, other callable, or something else entirely.) > > FWIW, I still disagree. Technically, it might not "wrap" anything (in the > sense > that it isn't defined as a function returning another function - which is a > narrow definition of a wrapper by the way), but semantically it does. To the > non-expert programmer, it is a decorator like any other one. The fact that it > is > implemented differently from other decorators is not an excuse for it to > follow > different rules... > > Unless, of course, there is a good *semantic* reason for staticmethod not to > mirror the __module__ attribute. > > (by the way, does the same apply to classmethod as well?)
Remember (a) these are implemented in C, and (b) they were created in Python 2.2, before we even had decorators (first introduced in 2.4). I'm fine with making them more transparent and conformant to emerging protocols, but they will always be a little different, due to being implemented as objects rather than functional wrappers. The latter approach *can* be used for decorator implementations to, it just is done rarely. I see this as something that can be done post beta 1. It has to be done while carefully remaining backwards compatible though. -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
