[pypy-dev] PyPy JVM Backend
Carl Friedrich Bolz
cfbolz at gmx.de
Sun Apr 29 12:34:15 CEST 2007
Antonio Cuni wrote:
> I agree, and this is why I mentioned the problem :-).
> I think there are two ways to make it working:
> 1) write a dummy CliFile (or JvmFile) subclass of stream, then
> special-case that class in the backend to map directly to
> System.Io.FileStream (or the Java equivalent)
> 2) make CliFile or JvmFile real classes, using the interpret-level
> bindings to forward the methods;
This is indeed the solution that I had in mind. Of course I forgot that
there are no interpreter-level bindings for Java yet, how hard would it
be to get them? We will need them anyway later. And writing them might
still be less work than writing the file descriptor implementation.
> then, we should modify open_file_as_stream and construct_stream_tower to
> instantiate these classes instead of the standard ones.
The result will be very cool because you can then use rlib.streamio and
get good cross-platform behavior.
> In both cases I also think it's not trivial to get all the combination
> of mode/options working, because .NET uses a slightly different set of
> options than posix to determine how to open a file (I don't know about
I don't think it is so bad. If you don't want to map the Python
semantics to the .NET ones, you can use the .NET stream only as the
lowestone in the stream tower and leave buffering and line endings to
the existing code. Or you can find an intermediate solution.
> About the app-level os.* functions; I also think that for now we could
> simply omit them, but in the long term we should write an alternative
> implementation based on streamio (IronPython does it in a similar way).
Yes, but this can probably even be done on applevel.
More information about the Pypy-dev