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__.
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 w
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
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 rid
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 runt
2009/7/14 Dino Viehland :
> 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 object.__new__() only complai
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 x(obj
