P.J. Eby wrote:
In effect, 2.6 forces you to have a common known base class *other* than
'object' in order to write co-operative classes. :-(
You have to do that anyway if you want to make cooperative
calls to any method *other* that __init__.
--
Greg
Dino Viehland wrote:
Based upon the behavior I'm seeing it seems to me that the
presence of __new__ / __init__ must be getting cached somewhere
and the deletion isn't updating the cache and that's specifically
what struck me as odd here.
Digging through typeobject.c, it isn't clear to me why
At 07:29 PM 7/15/2009 +1200, Greg Ewing wrote:
P.J. Eby wrote:
In effect, 2.6 forces you to have a common known base class *other*
than 'object' in order to write co-operative classes. :-(
You have to do that anyway if you want to make cooperative
calls to any method *other* that __init__.
I'm updating IronPython to match CPython's behavior w/ for this issue:
http://bugs.python.org/issue1683368
One thing that I've noticed is that this doesn't seem to be respecting the
deletion of attributes (on 2.6.2):
class x(object): pass
x().__init__(2,3,4) # throws - seems right
class
2009/7/14 Dino Viehland di...@microsoft.com:
Is this just a bug in CPython not updating whether __new__ has been
defined? Or is there something that makes this behavior expected which I’m
just missing?
There's a wonderful comment about this in typeobject.c:
/* You may wonder why
Benjamin wrote:
There's a wonderful comment about this in typeobject.c:
This is basically the same what I've gathered from the issue
description which was quite helpful. But in this case we're
dealing with mutating the type object and changing whether
__new__ or __init__ exist at all at
At 04:11 PM 7/14/2009 -0500, Benjamin Peterson wrote:
4. When __init__() is overridden, and the subclass __init__()
calls object.__init__(), the latter should complain about
excess arguments; ditto for __new__().
Actually, this rule is a PITA, because there's no good way to get
