We would really appreciate your contribution of the code for this, not to mention your help in general on JSR 223 compliance!

Re PyFileWriter - I restored PyFileWriter, based on http://bugs.jython.org/issue1266. At that time, I only implemented a limited subset of the functionality of PyFile, just sufficient for integration with sys.stdout/stderr. Because I only saw it as part of PythonInterpreter, and the overall direction was like NIO, to byte-oriented input/output, I marked it as deprecated. Long term it was unclear then that it was something we were going to support.

JSR 223 clarifies this situation: we have to support character-oriented IO for stdin/stdout/stderr to interoperate with 223. So we should undeprecate PyFileWriter and add Jim's proposed PyFileReader. But until advised otherwise, as Nicholas suggests, we should keep this purposefully limited to what's necessary for 223 and existing usage of PythonInterpreter.

- Jim

On Mon, Jul 27, 2009 at 5:42 PM, Jim White <jim@pagesmiths.com> wrote:
Nicholas Riley wrote:

> In article <4A6E1272.5050509@pagesmiths.com>,
>  Jim White <jim@pagesmiths.com> wrote:
>>I've looked a little at the PySystemState and PyFile stuff, and I could
>>whip up a PyFileReader like PyFileWriter to handle input if you like.
> That'd be great.

Will do.

>>I'm not totally clear on what's happening with character encodings
>>though (which I think may be a reason to keep PyFileWriter & Reader).
> Yeah, same here.  JSR 223 doesn't cover encodings at all and seems to
> just assume scripting languages do Unicode input and output when
> relatively few do (certainly, Python 2.x doesn't prefer Unicode, and
> Ruby seems even more byte-oriented internally).
> The best bet may be just to do *something* that looks acceptable and
> perhaps fix it later if we get bug reports.

Well, by sticking with Reader/Writer and doing the PyFileReader/Writer
thing we stay in Character land and don't need to worry about character
encoding.  If we were to go through the byte stream process then we'd
need to be sure the right encoding is used for encode/decode.

>>Also I see both std{in, out, err} and __std{in, out, err}__ in
>>PySystemState.  It seems that the __ versions are obsolete?  Or do they
>>have a particular purpose?
> The latter are standard Python attributes.  From
> <http://docs.python.org/library/sys.html>:
>>These objects contain the original values of stdin, stderr and stdout at the
>>start of the program. They are used during finalization, and could be useful
>>to print to the actual standard stream no matter if the sys.std* object has
>>been redirected.
>>It can also be used to restore the actual files to known working file objects
>>in case they have been overwritten with a broken object. However, the
>>preferred way to do this is to explicitly save the previous stream before
>>replacing it, and restore the saved object.

I see.  The "start of the program" business is a bit ambiguous in the
JSR-223 case.  If we leave the __ attributes alone then going to
java.io.System is a fair interpretation of the intent I suppose.

> PythonInterpreter doesn't overwrite __std{in,out,err}__, so I figured
> there was no point in doing so in JSR 223.

Well, the scripting.dev.java.net implementation of JSR-223 for Jython
set both versions and I didn't know why.

But since we've got two versions, I think having them be different in
this way (by not setting the __ versions) makes the difference
potentially useful.

The possible downside is if some folks were to use the __ attributes as
a matter of course, in which case they could get confused when running
in a JSR-223 context.  This can be handled with a bit of documentation I


Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
Jython-users mailing list

Jim Baker