On 20/05/2013 17:43, Jim Baker wrote:

In Jython 2.5 development, up through 2.5.0 RCs/final, we gave ourselves the freedom to break existing Java APIs such as PythonInterpreter. For subsequent 2.5.x releases, we grew the Java API, but kept it backwards compatible. This required a fair amount of contortions.

The general principle should continue to stand in 2.7. So you should feel free to do this refactoring. More below.

On Sat, May 18, 2013 at 2:12 AM, Jeff Allen <ja.py@farowl.co.uk> wrote:

The purpose of JLine is to provide a more convenient way for a user to
get (encoded) characters into a program than typing everything. I'll
call this its "console" function. However, in our current design,
JLineConsole is also a PythonInterpreter, working with lines of
characters treated as commands. It is only by separating the two
concerns, console and interpreter, that I've been able to make it work.
Although one bug fix shouldn't drive architecture, I think this provides
an architectural hint they should be separate.

Makes sense.
I spent a couple of days single-stepping through the initialisation and making notes. As a result understand this better. I found that initialisation is really orchestrated by PySystemState.doInitialize(). I found a spot in the middle of that where the registry is fully up, but the default PySystemState object has not yet been created.

I can hook a custom console in at this point that provides a shim to System.in before sys.stdin gets created on it. I've only tried it with a do-nothing-much shim:
>>> import sys
>>> print (sys._jy_console, sys.stdin.isatty())
(org.python.util.JAInteractiveConsole@213a8eb1, True)
>>> import java.lang.System
>>> java.lang.System.in
>>> raw_input()

The names are temporary while I need old and new approaches concurrently. I've only sketched a JLine one, and how it would play with readline.py, but it looks possible.

I believe we still need org.python.util.ReadlineConsole to work: is that right?