Carl Friedrich Bolz wrote: > I think it is the time now to do away with the file descriptor > simulation, it was useful at one point but is very silly now. Instead, a > subclass of pypy.rlib.streamio.Stream should be created that only > delegates to the Java/.NET Stream classes, probably making use of the > facilities for buffering that the platforms offer. I think it is > perfectly reasonable to not have os.open and friends on pypy.net as long > as file works. If another placeof pypy still uses os.open I am strongly > for fixing that.
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; then, we should modify open_file_as_stream and construct_stream_tower to instantiate these classes instead of the standard ones. 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 Java). I think that solution (2) is easier to implement and more readable, but so far it's possible only for gencli because genjvm doens't provide interp-level bindings to java libraries. By contrast Solution (1) is not trivial to implement if the interfaces of our Stream class and the Java's one are very different. Maybe a better solution would be to map the dummy streamio.JvmFile to a class written in Java doing the necessary conversions and forwarding to the native stream class. 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). ciao Anto _______________________________________________ [email protected] http://codespeak.net/mailman/listinfo/pypy-dev
