From: Updike, C. <Cla...@jh...> - 2005-06-10 03:53:46
|
New-style class changes to PyFile seem to have=20 broken test_javashell because attempts to use the java constructors on PyFile from jython fail since apparently only the open() style arguments work (handled by PyFile.file_init). =20 There was some attempt to resolve this by=20 replacing references to the java constructors=20 with java.io stream instances, but there are=20 still problems with javashell and popen2. Shouldn't the explicit PyFile constructors still be=20 usable from jython like they were in 2.1? Otherwise, popen2.py ProcessFile.__init__ has no way to make a=20 PyFile from a stream, AFAICT. I'd take a crack at it myself, but I'm not sure what the fix to PyFIle is. -Clark |
From: Brian Z. <bz...@zi...> - 2005-06-10 11:23:26
|
You beat me to this post. Historically we've made no attempt to isolate the Jython internals, such as PyFile and PyString, from their Jython runtime, file and str, types. In pre new-style classes there was no clear distinction between Jython internal API and Jython. Calling Jython Java was like calling any other Java. Now the line between Jython internal API and Jython the language is more defined. Unlike before when Java-Jython integration was based on exclusion (through classDictInit, PyIgnoreMethodTag, or some other such mechanism) it's switched to inclusion through the exposed methods. This is more in-line with the CPython development model where there can be CPython API which Python cannot call. So this is really only a problem when Python code calls into Jython's internal API. One sort of hack I was looking at was extending the _jython module to forward the calls from Python to Jython internal API as necessary. This isn't necessarily the best approach but it would certainly be a viable short term fix. The correct way I think would be either to open up the constructors for PyFile beyond those allowed by Python the language or force popen2 to create a new file-like class which delegates appropriately. Since this is a somewhat common case I think extending the constructor for PyFile and exposing it is probably the best approach. We can grow the PyFile constructor to look for keywords referencing the appropriate streams or readers. If they are there, then use them, otherwise the existing constructor functionality should be used. This should be listed as a deviance from CPython but one which makes sense in our world. The CPython world uses file descriptors far more prevalently than we do so this is kind of analogous to that model. Hmm, now that I just wrote that, how about using os.fdopen instead of the file constructors? We (I don't have source in front of me) don't really use fdopen do we? We could write a new os-module method which took streams or readers and constructed the PyFile instance. Again, though, this isn't possible if the os logic is written in Python. Nah, stick with the PyFile constructor arguments. thanks, brian On Jun 9, 2005, at 10:53 PM, Updike, Clark wrote: > New-style class changes to PyFile seem to have > broken test_javashell because attempts to use the > java constructors on PyFile from jython > fail since apparently only the open() style > arguments work (handled by PyFile.file_init). > There was some attempt to resolve this by > replacing references to the java constructors > with java.io stream instances, but there are > still problems with javashell and popen2. > > Shouldn't the explicit PyFile constructors still be > usable from jython like they were in 2.1? Otherwise, > popen2.py ProcessFile.__init__ has no way to make a > PyFile from a stream, AFAICT. > > I'd take a crack at it myself, but I'm not sure what > the fix to PyFIle is. > > -Clark > > > ------------------------------------------------------- > This SF.Net email is sponsored by: NEC IT Guy Games. How far can you > shotput > a projector? How fast can you ride your desk chair down the office > luge track? > If you want to score the big prize, get to know the little guy. > Play to win an NEC 61" plasma display: http://www.necitguy.com/?r > _______________________________________________ > Jython-dev mailing list > Jyt...@li... > https://lists.sourceforge.net/lists/listinfo/jython-dev |
From: Frank W. <fwi...@gm...> - 2005-06-10 21:38:18
|
All, Since this is my bad, I can try to get this fixed over the weekend.=20 That is unless one of you is fixing it already... Frank On 6/10/05, Brian Zimmer <bz...@zi...> wrote: > You beat me to this post. >=20 > Historically we've made no attempt to isolate the > Jython internals, such as PyFile and PyString, from > their Jython runtime, file and str, types. In pre > new-style classes there was no clear distinction > between Jython internal API and Jython. Calling > Jython Java was like calling any other Java. Now > the line between Jython internal API and Jython the > language is more defined. >=20 > Unlike before when Java-Jython integration was based > on exclusion (through classDictInit, PyIgnoreMethodTag, > or some other such mechanism) it's switched to inclusion > through the exposed methods. This is more in-line > with the CPython development model where there can be > CPython API which Python cannot call. >=20 > So this is really only a problem when Python code > calls into Jython's internal API. One sort of hack > I was looking at was extending the _jython module > to forward the calls from Python to Jython internal > API as necessary. This isn't necessarily the best > approach but it would certainly be a viable short > term fix. >=20 > The correct way I think would be either to open > up the constructors for PyFile beyond those allowed > by Python the language or force popen2 to create a > new file-like class which delegates appropriately. >=20 > Since this is a somewhat common case I think extending > the constructor for PyFile and exposing it is probably > the best approach. We can grow the PyFile constructor > to look for keywords referencing the appropriate streams > or readers. If they are there, then use them, otherwise > the existing constructor functionality should be used. >=20 > This should be listed as a deviance from CPython but > one which makes sense in our world. The CPython world > uses file descriptors far more prevalently than we > do so this is kind of analogous to that model. >=20 > Hmm, now that I just wrote that, how about using os.fdopen > instead of the file constructors? We (I don't have source > in front of me) don't really use fdopen do we? We could > write a new os-module method which took streams or readers > and constructed the PyFile instance. Again, though, this > isn't possible if the os logic is written in Python. Nah, > stick with the PyFile constructor arguments. >=20 > thanks, >=20 > brian >=20 > On Jun 9, 2005, at 10:53 PM, Updike, Clark wrote: >=20 > > New-style class changes to PyFile seem to have > > broken test_javashell because attempts to use the > > java constructors on PyFile from jython > > fail since apparently only the open() style > > arguments work (handled by PyFile.file_init). > > There was some attempt to resolve this by > > replacing references to the java constructors > > with java.io stream instances, but there are > > still problems with javashell and popen2. > > > > Shouldn't the explicit PyFile constructors still be > > usable from jython like they were in 2.1? Otherwise, > > popen2.py ProcessFile.__init__ has no way to make a > > PyFile from a stream, AFAICT. > > > > I'd take a crack at it myself, but I'm not sure what > > the fix to PyFIle is. > > > > -Clark > > > > > > ------------------------------------------------------- > > This SF.Net email is sponsored by: NEC IT Guy Games. How far can you > > shotput > > a projector? How fast can you ride your desk chair down the office > > luge track? > > If you want to score the big prize, get to know the little guy. > > Play to win an NEC 61" plasma display: http://www.necitguy.com/?r > > _______________________________________________ > > Jython-dev mailing list > > Jyt...@li... > > https://lists.sourceforge.net/lists/listinfo/jython-dev >=20 > |
From: brian z. <bz...@zi...> - 2005-06-11 10:20:56
|
I wasn't going to actively fix it but rather I wanted to figure out how we'd handle these situations going forward. It's likely that other code is using non-public Jython API. brian > All, > > Since this is my bad, I can try to get this fixed over the weekend. > That is unless one of you is fixing it already... > > Frank > > On 6/10/05, Brian Zimmer <bz...@zi...> wrote: >> You beat me to this post. >> >> Historically we've made no attempt to isolate the >> Jython internals, such as PyFile and PyString, from >> their Jython runtime, file and str, types. In pre >> new-style classes there was no clear distinction >> between Jython internal API and Jython. Calling >> Jython Java was like calling any other Java. Now >> the line between Jython internal API and Jython the >> language is more defined. >> >> Unlike before when Java-Jython integration was based >> on exclusion (through classDictInit, PyIgnoreMethodTag, >> or some other such mechanism) it's switched to inclusion >> through the exposed methods. This is more in-line >> with the CPython development model where there can be >> CPython API which Python cannot call. >> >> So this is really only a problem when Python code >> calls into Jython's internal API. One sort of hack >> I was looking at was extending the _jython module >> to forward the calls from Python to Jython internal >> API as necessary. This isn't necessarily the best >> approach but it would certainly be a viable short >> term fix. >> >> The correct way I think would be either to open >> up the constructors for PyFile beyond those allowed >> by Python the language or force popen2 to create a >> new file-like class which delegates appropriately. >> >> Since this is a somewhat common case I think extending >> the constructor for PyFile and exposing it is probably >> the best approach. We can grow the PyFile constructor >> to look for keywords referencing the appropriate streams >> or readers. If they are there, then use them, otherwise >> the existing constructor functionality should be used. >> >> This should be listed as a deviance from CPython but >> one which makes sense in our world. The CPython world >> uses file descriptors far more prevalently than we >> do so this is kind of analogous to that model. >> >> Hmm, now that I just wrote that, how about using os.fdopen >> instead of the file constructors? We (I don't have source >> in front of me) don't really use fdopen do we? We could >> write a new os-module method which took streams or readers >> and constructed the PyFile instance. Again, though, this >> isn't possible if the os logic is written in Python. Nah, >> stick with the PyFile constructor arguments. >> >> thanks, >> >> brian >> >> On Jun 9, 2005, at 10:53 PM, Updike, Clark wrote: >> >> > New-style class changes to PyFile seem to have >> > broken test_javashell because attempts to use the >> > java constructors on PyFile from jython >> > fail since apparently only the open() style >> > arguments work (handled by PyFile.file_init). >> > There was some attempt to resolve this by >> > replacing references to the java constructors >> > with java.io stream instances, but there are >> > still problems with javashell and popen2. >> > >> > Shouldn't the explicit PyFile constructors still be >> > usable from jython like they were in 2.1? Otherwise, >> > popen2.py ProcessFile.__init__ has no way to make a >> > PyFile from a stream, AFAICT. >> > >> > I'd take a crack at it myself, but I'm not sure what >> > the fix to PyFIle is. >> > >> > -Clark >> > >> > >> > ------------------------------------------------------- >> > This SF.Net email is sponsored by: NEC IT Guy Games. How far can you >> > shotput >> > a projector? How fast can you ride your desk chair down the office >> > luge track? >> > If you want to score the big prize, get to know the little guy. >> > Play to win an NEC 61" plasma display: http://www.necitguy.com/?r >> > _______________________________________________ >> > Jython-dev mailing list >> > Jyt...@li... >> > https://lists.sourceforge.net/lists/listinfo/jython-dev >> >> > > |
From: Frank W. <fwi...@gm...> - 2005-06-11 15:14:48
|
I'm hoping that many cases can be solved by replacing the non-public calls with calls into basic java api's (like we did in javashell.py).=20 However, I haven't really looked into the Jython Lib code enough to know the extent of the problem. In cases where replacement with java api calls is too hard I like the idea of having special keywords for internal class constructors like (perhaps) "jinputstream" and "jreader" for PyFile. Anyhow, I'll start looking for PyFile and PyString calls in jythons Lib files. I'll start on the cases that can be easily replaced with java api calls while we are deciding what to do in the more difficult cases. Frank On 6/11/05, brian zimmer <bz...@zi...> wrote: > I wasn't going to actively fix it but rather I wanted to > figure out how we'd handle these situations going > forward. It's likely that other code is using non-public > Jython API. >=20 > brian |
From: Frank W. <fwi...@gm...> - 2005-06-12 00:04:24
|
If we do decide to use the new keyword approach, what about adding the keyword "filewrapper" and use PyFile.FileWrapper (and its subclasses) for the various streams. This would keep us from needing a new keyword to support RandomAccessFile, the nio channel stuff etc. Then we could write code like fw =3D PyFile.InputStreamWrapper(inputstream) pf =3D file(filewrapper(fw)) Thoughts? Frank |