Issue1171

When trying to create a PyFile from a java.io.InputStream, a TypeError
is created. The following snippet illustrates

# filebug.py -=-=-=-=-=-=-=-=-=-=-=
from java.io import FileInputStream
from org.python.core import PyFile

fis = FileInputStream("error.txt")
pyf = PyFile(fis)
#-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

Which outputs 

Traceback (most recent call last):
  File "filebug.py", line 7, in <module>
    pyf = PyFile(fis)
TypeError: coercing to Unicode: need string, 'javainstance' type found

This bug was introduced sometime between 2.5a3 and 2.5b0.

It was reported by two different modjy users.

http://groups.google.com/group/web2py/browse_thread/thread/c899d456c146e2bc

One of them on Frank's blog

http://fwierzbicki.blogspot.com/2008/10/jython-25-beta0-released.html

Until this is fixed, I can only recommend to users not to use modjy with
jython 2.5b0; use a previous version instead.

Alan, there was a recent backwards incompatible change that will mean
that the code sample you have posted would need to be changed to:

from java.io import FileInputStream
from org.python.core.util import FileUtil

fis = FileInputStream("error.txt")
pyf = FileUtil.wrap(fis)

I've started a conversation on the jython-dev list about this.

We decided on:

o Nuking support for In/OutputStream in file() and PyFile(). groves 
originally did this, mostly because supporting this requires a really 
gross hack

o Going forward we want this functionality to live elsewhere, in 
FileUtil.wrap

o However since open is now a function in 2.5, supporting 
In/OutputStreams there isn't such a lame hack -- so I've added support 
for this there in r5606 -- albeit deprecated. Using open on streams will 
work on 2.5 but emit a DeprecationWarning to use FileUtil instead. We'll 
remove this in 2.6

So modjy should really move to FileUtil if sys.version_info >= (2, 5)

I reported the same problem in http://bugs.jython.org/issue1204, not
having found this one in my search. I realize the case is closed, but I
wanted to record some background in case it ever gets revisited.

The application that broke for me was a unit test rig (and accompanying
application shell) that tested equivalent interfaces in both .NET (with
IronPython) and Java (with Jython). Jython and IronPython both allowed
constructing file objects from .NET/Java streams by using the file()
constructor, which I tried because it seemed obvious. And then I used it
because I had achieved compatibility without having to resort to some
adapter function.

I know it's rather odd to discuss feature parity with some other Python
implementation that isn't CPython. I've found it quite useful that the
two implementations are as compatible as they are.

I must confess that I was a little perplexed by the change myself,
especially when you look at the wrap() code

    public static PyFile wrap(InputStream is, int bufsize) {
        return new PyFile(is, bufsize);
    }

    public static PyFile wrap(InputStream is) {
        return wrap(is, -1);
    }

This could have been dealt with by adding extra constructors for
PyFile(InputStream) with defaults for the bufsize parameter.