On 05/12/2012 00:07, Philip Jenvey wrote:
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 
understand this?


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.

Philip Jenvey

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.

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.

Jeff Allen