Arnaud Delobelle a écrit :
[EMAIL PROTECTED] wrote:
On 14 mai, 22:44, Arnaud Delobelle <[EMAIL PROTECTED]> wrote:
"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> writes:
On 14 mai, 19:45, Arnaud Delobelle <[EMAIL PROTECTED]> wrote:
__new__ is a static method!
__new__ is a special-cased staticmethod that 1/ must not be declared
as such and 2/ takes the class object as first args. As far as I'm
concerned, it's semantically a classmethod.
It's a static method!
OK then let me reply pedantically:
Sorry Arnaud, I probably didn't made it clear enough : I do know it is
a staticmethod object. What I say is that
1/ it's special-cased since you don't *explicitely* declare it as a
staticmethod
In some cases you have to:
class Foo(object): pass
# Later on I want to redefine Foo.__new__
@staticmethod
def Foo__new__(cls):
print "new Foo!"
return object.__new__(cls)
Foo.__new__ = Foo__new__
Foo()
New Foo!
# Without the @staticmethod we would get a TypeError
Point taken. But you'll admit that monkeypatching the __new__ method is
somewhat uncommon !-)
2/ it behaves
<nb>
Poor word choice here I'm afraid - of course a staticmethod doesn't
"behave" like a classmethod object. But you of course __knew__ what I
meant !-)
</nb>
just like a classmethod, since it takes the class as
first argument.
When you invoke it implicitely maybe, but not when you do so
explicitely!
I'm not talking about how you invoke it (FWIW, direct invocation of
__new__ is pretty rare, parent call excepted - and then, well, it mostly
mirrors a direct parent call within an overridden instance method). It's
about having __new__ taking the class as first argument.
FWIW, I wonder why the BDFL choosed to implement __new__ as a
staticmethod - there are probably some pretty good reasons, but not
knowing them, it looks like __new__ would have been a perfect candidate
for a classmethod.
So far, the only reason I can think of is that making it a classmethod
would have required the use of super(Parent, cls) to call the parent's
class __new__, which may (or may not - never had the case) be
problematic (any guru on this ?)
IOW, I'm talking about semantic, not implementation.
I understand what you mean, and from that point of view you can argue
against my example above
It's somehow difficult to argue against something that's just the plain
and naked truth. My one and only argument is about __new__ being
semantically close enough to a classmethod to wonder why it isn't one.
(after all, my example is code, not pure
concept) but for me it is simpler to think of __new__ as a
staticmethod (which it is!), plain and simple.
I could by no mean hold it against you !-)
--
http://mail.python.org/mailman/listinfo/python-list
