Title: Re-align the logic of with CPython 2.7 equivalent
Type: behaviour Severity: normal
Components: Core Versions: Jython 2.7
Status: open Resolution:
Dependencies: Superseder:
Assigned To: jeff.allen Nosy List: jeff.allen
Priority: normal Keywords: console

Created on 2018-05-17.19:50:41 by jeff.allen, last changed 2018-05-17.19:50:41 by jeff.allen.

msg11991 (view) Author: Jeff Allen (jeff.allen) Date: 2018-05-17.19:50:40
The logic of Jython's main run() program has become quite tortured, especially regarding the treatment of interactive mode and when to install a line-editing console.

We have a reliable indication (from the launcher) whether out standard input is in fact an interactive console. However, we may not be making full use of it. It woould be good not to depend on isatty here as that depends on reflective access to private data, and as if that were not enough, we are promised it will break in a future version of Java.

When a tty stream is given as an argument ("jython /dev/stdin" or "jython CON"), so that isatty returns true, run() adapts its method of reading to the result of isatty(). However, the behaviour is still not console friendly, since it attempts to read 8192 bytes at once and seems not to recognise line ends.

The logic of CPython's main.c, which has the same purpose as Jython's run(), is also a little complex but is easier to follow. Moreover, it provides the expected behaviour. We should model run() more closely on the reference implementation, diverging only where Java requires it.

Against this, we have made some changes to run() specifically to support ipython, and change risks breaking that. ( Possibly the requirement is simply to let a client program "type at the prompt" -- there's no .py file to execute, so it is "interactive" in that sense, yet should be line-oriented. It's not clear we do the right thing anymore in these circumstances, which are incidentally also those of #2525.
Date User Action Args
2018-05-17 19:50:41jeff.allencreate