I will keep a grace period in mind when I am posting. In my defense,
however, I had been working on the problem for some time before posting this
and my messages in quick succession were in response to the suggestions
people offered. The problem has arisen again but I will work on it some more
and
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
The problem appears resolved again and I have two posts on the issue on my
blog located at http://subdev.blogspot.com/. I was missing an MSVC++
run-time DLL and re-installing Visual C++ Express fixed the problem. A bit
of a somewhat random note -- looking through some of the buildbot output for
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
I implemented get_filename() as specified in PEP 302 for importlib's source
and bytecode loaders and I was starting to create the ABC for importlib.abc,
but then I realized that perhaps the loader should live in runpy instead of
importlib.
Putting the new ABC in importlib keeps all PEP 302 ABCs in
