On 05/12/2012 00:07, Philip Jenvey wrote:
Thanks Philip. This doesn't appear to be specific to exceptions. I'm
sure I could make it happen with regular classes too, but for now
I'll log it as a bug and if no-one has fixed it when I come to a
stop on io, I'll circle back.
On Dec 2, 2012, at 12:48 PM, Jeff Allen wrote:
I've run across what may be a bug in the core treatment of multiple
inheritance when the slots array is active in a base. Does anyone
I've tracked the problematic logic down to PyType.createAllSlots(),
called from PyType newType(), which only takes notice of the number of
slots in the first base mentioned (which becomes type.base) rather than
making some aggregation involving all the bases. This is probably a bug,
but does anyone know what should happen in this method - what the rules
are governing __slots__ and inheritance?
It seems to me there would have to be some relocation of slots in some
circumstances: does that work?
This is a nasty ;] because:
a) the spec of how slots are handled, especially with inheritance, is pretty obscure. You can maybe get some idea from our test_slots_jy.py
b) the fact that our base exceptions define __slots__ is kind of a hack to simulate CPython's base exception attributes (that are stored as slot-like 'structure members' instead of in the __dict__):
Python 2.5.4 (r254:67916, Aug 1 2011, 15:52:49)
[GCC 4.2.1 (Apple Inc. build 5646)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
e = IOError()
e.errno = 3
e.errno # it's there, just inside of the instance's struct. similar to a slot
Exception dicts are created lazily. So the point of all this is that exceptions don't need a dictionary allocated unless you're storing non-standard, arbitrary attributes on them.
but it looks like this __slots__ hack falls apart here. It *seems* like a bug in the slots handling. It'd be nice to reproduce this case without the exceptions as it would prove that (and would be a nice test for test_slots_jy.py). Otherwise maybe it's some strange interaction with how we're defining these exception slots.
I've been reading exceptions.java however, and the way those are
constructed in Jython does seem ... exceptional. I was wondering if
it was a fosssil of how exposed classes were once created in the
core. I've emulated it for UnsupportedOperation, but I'm not sure
how I'll do it for BlockingIOError which has its own __init__. Its
not needed just yet. A lot of the methods one might call to aid are
(currently) private in exceptions.java.