From: Jim W. <ji...@pa...> - 2009-07-25 18:34:41
|
Howdy Jythonfolk. I just tried out the JSR-223 engine in the 2.5 trunk and it works dandy (handling both statements and expressions - yay!) except that it doesn't handle the I/O part of the API. I opened an issue and included a quickie patch to implement output. If more help is needed to get this fixed, then just let me know. http://bugs.jython.org/issue1408 Jim |
From: Nicholas R. <nj...@ui...> - 2009-07-26 07:52:21
|
In article <4A6...@pa...>, Jim White <ji...@pa...> wrote: > I just tried out the JSR-223 engine in the 2.5 trunk and it works dandy > (handling both statements and expressions - yay!) except that it doesn't > handle the I/O part of the API. > > I opened an issue and included a quickie patch to implement output. If > more help is needed to get this fixed, then just let me know. > > http://bugs.jython.org/issue1408 I've checked in the stderr/stdout redirection but I haven't yet had a chance to write tests for it. This once again runs into the issue that the NIO-enabled Jython I/O system really does not want char-oriented I/O coming from Java any more. There's only PyFileWriter, which was removed, then was restored for backwards compatibility and is now deprecated. If JSR 223 requires it, maybe we should un-deprecate this path (while still recommending against its use for optimal performance) and incorporate something equivalent on the reading side via PythonInterpreter.setIn(), perhaps using your ReaderInputStream. I'm not terribly familiar with the issues surrounding Java I/O, though. -- Nicholas Riley <nj...@ui...> |
From: Jim W. <ji...@pa...> - 2009-07-27 20:47:58
|
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. I'm not totally clear on what's happening with character encodings though (which I think may be a reason to keep PyFileWriter & Reader). 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? Jim Nicholas Riley wrote: > In article <4A6...@pa...>, > Jim White <ji...@pa...> wrote: > > >>I just tried out the JSR-223 engine in the 2.5 trunk and it works dandy >>(handling both statements and expressions - yay!) except that it doesn't >>handle the I/O part of the API. >> >>I opened an issue and included a quickie patch to implement output. If >>more help is needed to get this fixed, then just let me know. >> >>http://bugs.jython.org/issue1408 > > > I've checked in the stderr/stdout redirection but I haven't yet had a > chance to write tests for it. This once again runs into the issue that > the NIO-enabled Jython I/O system really does not want char-oriented I/O > coming from Java any more. There's only PyFileWriter, which was > removed, then was restored for backwards compatibility and is now > deprecated. > > If JSR 223 requires it, maybe we should un-deprecate this path (while > still recommending against its use for optimal performance) and > incorporate something equivalent on the reading side via > PythonInterpreter.setIn(), perhaps using your ReaderInputStream. I'm > not terribly familiar with the issues surrounding Java I/O, though. |
From: Nicholas R. <nj...@ui...> - 2009-07-27 21:13:49
|
In article <4A6...@pa...>, Jim White <ji...@pa...> 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. > 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. > 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. PythonInterpreter doesn't overwrite __std{in,out,err}__, so I figured there was no point in doing so in JSR 223. -- Nicholas Riley <nj...@ui...> |
From: Jim W. <ji...@pa...> - 2009-07-27 23:42:35
|
Nicholas Riley wrote: > In article <4A6...@pa...>, > Jim White <ji...@pa...> 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 think. Jim |
From: Jim B. <jb...@zy...> - 2009-07-28 01:28:58
|
Jim, 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 <ji...@pa...> wrote: > Nicholas Riley wrote: > > > In article <4A6...@pa...>, > > Jim White <ji...@pa...> 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 > think. > > Jim > > > > ------------------------------------------------------------------------------ > 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 > Jyt...@li... > https://lists.sourceforge.net/lists/listinfo/jython-users > -- Jim Baker jb...@zy... |
From: Jim W. <ji...@pa...> - 2009-07-28 06:17:43
|
I've added a patch against the current trunk to add a first cut for PyFileReader. http://bugs.jython.org/issue1408 It is a bit of a hack in that rather than implementing readline(len) to do the line handling itself, it punts it down to java.io.BufferedReader. That means it treats any call as being readline(-1). Included some minimal tests. Jim |
From: Nicholas R. <nj...@ui...> - 2009-07-31 19:31:18
|
In article <4A6...@pa...>, Jim White <ji...@pa...> wrote: > It is a bit of a hack in that rather than implementing readline(len) to > do the line handling itself, it punts it down to java.io.BufferedReader. > That means it treats any call as being readline(-1). I changed this to throw an exception - hopefully it should never be an issue in practice. -- Nicholas Riley <nj...@ui...> |