Some of this is beginning to make sense. I've discovered:
- The "plausible stuff happening ... difficult to know whether
it is meant to happen", is not supposed to happen. I made a typo
in CoreExposed.includes, and that's why constructors in my
PyRawIOBase were being searched reflectively.
- If PyRawIOBase is properly exposed, __new__ is called and as
we return, __init__ would be called in some circumstances.
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, email@example.com
On Sun, Sep 30, 2012 at 7:40 AM, Jeff
spread the goodness of _io.PyFileIO.java up a hierearchy of
PyFileIO.java, PyRawIOBase.java and _IOBase.java in a way I
roughly correct, but nothing works yet: the test program
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
implemented, and don't know where to look. At least, I've no
should happen when Jython tries to instantiate
spent some time single-stepping through attempts at
invocation of my constructors. I can see plausible stuff
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'>,
'_io._IOBase'>, <type 'object'>]. Along the way,
Jython must have to
create a PyRawIOBase, or maybe a PyRawIOBaseDerived, that in
one of the multiply-inherited base classes of
Eventually it should find and call
later MockRawIOWithoutRead.readinto() (we're in
The argument MockRawIOWithoutRead.__init__() should get,
which is a
tuple of strings to be treated as lines of a virtual file is
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
creates in these circumstances, and a narrative on how it
them to find methods and constructors. Is there really
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.
Most devs has no idea what their production app looks like.
Find out how fast your code is with AppDynamics Lite.
Jython-dev mailing list