Test failures in the revised approach to PEP-3116 IO are now slightly lower than when I started work.

I have (I think) passed through a phase of being thoroughly confused by the interplay of inheritance (in Java, Python, CPython and Jython), PEP-3116 layering, and delegation to classes from org.python.core.io. In the end, I had to make a big spreadsheet of all the parts I'd worked on and how they implement their methods. I think I have learned that the only safe thing is to mimick the Python reference implementation _pyio as closely as possible.

I have been following a design, outlined at the start of this thread, that involves delegation to the implementation Philip Jenvey has given us in org.python.core.io. I'm now convinced this won't work as planned. Philip's implementation does indeed mimick the _pyio one well (or differences that may have appeared in _pyio after his work could easily be added), but the overriding of abstract or stub methods in base classes is only available to Java, whereas it must be possible to override them in Python. As an isolated example, a call to flush() occurring in FileIO.close() must invoke a flush() defined by a Python subclass of _io.FileIO. The only solution I see is for my class to provide its own implementation of _io.FileIO.close(), rather than delegate to Philip's, and the same logic applied across all classes an methods means my implementation in org.python.modules._io has to stand alone. Philip's code is certainly a good model for it, but it doesn't seem possible to delegate to it. (There may be something about *Derived classes that I'm missing.)

Given the test scores, I'm at the point where pushing to the repo would do slightly more good than harm, technically. However, I can see major change on the way. What would be most useful?

Jeff Allen