Some of this is beginning to make sense. I've discovered:

Now that __new__ is being called, I can see better how this is supposed to work. But I still don't really have the picture in my head of the data structure being built and navigated.

Can anyone say where (in Java) MockRawIOWithoutRead.__init__() should get called from, and when? Is that done in the generated code defined in Python or in support code written in Java?


On 01/10/2012 08:03, Jeff Allen wrote:
Thanks Frank. I've got a change set to push (just the renaming of modules) then when I've tidied up a bit -- no point confusing things further -- I'll post a patch of my broken bits so far.


On 30/09/2012 22:05, wrote:

On Sun, Sep 30, 2012 at 7:40 AM, Jeff Allen <> wrote:
I've spread the goodness of up a hierearchy of, and in a way I think is
roughly correct, but nothing works yet: the test program (test_io)
cannot construct the classes that extend mine. This is really taxing my
understanding of how Jython is implemented.

It is more accurate to say I have almost no idea how Jython is
implemented, and don't know where to look. At least, I've no idea what
should happen when Jython tries to instantiate CMockIOWithoutRead. I've
spent some time single-stepping through attempts at reflective
invocation of my constructors. I can see plausible stuff happening but
it is very difficult to know whether it is meant to happen, or is some
kind of fall-back.

The mro is [<class '__main__.CMockRawIOWithoutRead'>, <class
'__main__.MockRawIOWithoutRead'>, <class 'io.RawIOBase'>, <type
'org.python.modules._io.PyRawIOBase'>, <class 'io.IOBase'>, <type
'_io._IOBase'>, <type 'object'>]. Along the way, Jython must have to
create a PyRawIOBase, or maybe a PyRawIOBaseDerived, that in Python is
one of the multiply-inherited base classes of CMockRawIOWithoutRead.
Eventually it should find and call MockRawIOWithoutRead.__init__(), and
later MockRawIOWithoutRead.readinto() (we're in test_RawIOBase_read).
The argument MockRawIOWithoutRead.__init__() should get, which is a
tuple of strings to be treated as lines of a virtual file is not
something any PyRawIOBase constructor is likely to expect, but Jython is
looking for one and giving up when it is not found. Should there be one
accepting the generic args[], kwargs[] arguments to be called and do
nothing when _io._RawIOBase is the "wrong" base class?

I could really do with a picture of the data structures that Jython
creates in these circumstances, and a narrative on how it would traverse
them to find methods and constructors. Is there really *nothing* written
down for the next generation of developers?
The method dispatch code is indeed entirely undocumented and fairly complicated - would you mind posting a patch somewhere (maybe here)? I think looking at what you have and getting my own head together on the subject as I try to explain could help me start a doc.


Got visibility?
Most devs has no idea what their production app looks like.
Find out how fast your code is with AppDynamics Lite.;262219671;13503038;y?

Jython-dev mailing list