Issue695383

The behavior that I'm seeing is:

% jython
Jython 2.1+ on java1.3.1_02 (JIT: null)
Type "copyright", "credits" or "license" for more
information.
>>> import sys
>>> sys.stdout.close()
Traceback (innermost last):
  (no code object) at line 0
ValueError: I/O operation on closed file
%

On the other hand, under CPython:

% python
Python 2.2 (#1, Feb 26 2002, 15:49:15) 
[GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-81)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import sys
>>> sys.stdin.close()
>>>

I understand raising ValueError, but I can't seem to
even catch
the exception.

trunk works like CPython now in this regard:

Jython 2.3a0+ (trunk:4553:4564M, Jun 7 2008, 21:19:17) 
[Java HotSpot(TM) Client VM (Apple Inc.)] on java1.5.0_13
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.stdout.close()
>>> print 'hi'
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: I/O operation on closed file
>>> print 'hi'
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ValueError: I/O operation on closed file
>>> try:
...     print 'hi'
... except ValueError:
...     print >> sys.stderr, 'hi'
... 
hi
>>> 

(and note the ValueError didn't occur until I tried printing something)

my mistake, we're ok when sys.stdin is closed, but we still quit when 
sys.stdout is closed

it looks like we end up exiting because we actually write our prompt 
'>>>' to sys.stdout. So writing to the closed stdout raises a 
ValueError, breaking us out of the interactive prompt loop (causing the 
exit)

We should actually be writing the prompt to stderr -- that will totally 
avoid the exception.

The problem with that is when readline is enabled, the only way we can 
write the prompt to stderr instead of stdout is by doing it ourselves 
(right now Readline.readline() writes the prompt for us).

This seems to break readline in some situations: for example, when 
recalling a previous line in the history (with the up arrow), readline 
for some reason doesn't realize there's a prompt at the beginning of the 
line and allows you to muck with those characters

This is no longer a problem with the default JLine console but still 
happens on the pure java version

doesnt work:
sys.stderr.write('hi')

works:
print >> sys.stderr, 'entering function'

Apparently the issue is back even for our JLine-based console, with a new exception thrown in the mix:

$ jython27
Jython 2.7b3+ (default:7516d3820146+, Jun 18 2014, 22:11:17)
[Java HotSpot(TM) 64-Bit Server VM (Oracle Corporation)] on java1.7.0_21
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys; sys.stdin.close()
>>> ValueError: I/O operation on closed file
$

and

$ jython27
Jython 2.7b3+ (default:7516d3820146+, Jun 18 2014, 22:11:17)
[Java HotSpot(TM) 64-Bit Server VM (Oracle Corporation)] on java1.7.0_21
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys; sys.stdout.close()
Exception in thread "main"
Exception: org.python.core.PyException thrown from the UncaughtExceptionHandler in thread "main"
$

No surprise given our recent console cleanup work.

I believe this issue (or a similar one) is causing a failure in test_json (json.tests.test_tool.TestTool.test_infile_stdout). This is with Jython 2.7b3+ / java1.7.0_40 / osx 10.9.4.

That test ends up calling json.tool, which has (simplified) code similar to:

with sys.stdout:
    #do stuff

When the context manager calls sys.stdout.__exit__ it closes sys.stdout. Later execfile in PythonInterpreter.java is called, which calls Py.flushLine(), which eventually attempts to close sys.stdout. That fails (it's already closed) and org.python.core.PyException gets thrown causing the test to fail.

Since this is not happening from the interactive console it's possible this a similar looking yet different problem. Not sure what the fix to this is, just sharing what I found out when digging into a test failure.

Still valid:

Jython 2.7.2a1+ (default:d74f8c2cd56f, Feb 24 2018, 17:18:53)
[Java HotSpot(TM) 64-Bit Server VM (Oracle Corporation)] on java1.8.0_151
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.stdout.close()
Exception in thread "main"
Exception: org.python.core.PyException thrown from the UncaughtExceptionHandler in thread "main"

It is as if the console ought to be a layer *below* sys.std[in|out|err] that could still talk when those Python channels are closed. At present, we issue the prompt *through* them, using raw_input(">>>").

In my thinking, this lower layer is also necessary so that multiple interpreters may have a sys.std[in|out|err] each, which any one of them could close independently, while others continue to support print() etc..