[Web-SIG] Pending modifications to PEP 333
py-web-sig at xhaus.com
Wed Sep 1 12:52:02 CEST 2004
[Phillip J. Eby]
> I'm just about to check in a major update to the PEP, per the details
Thanks for all your hard work: I think you're doing a great job, and I
think that the WSGI initiative is the best thing ever to happen to
python web APIs.
But I do have one problem :-(
[Phillip J. Eby]
> I've also clarified that 'fileno()', if present, *must* be an OS file
> descriptor, and is only relevant to servers on platforms where file
> descriptors exist.
This will break portability across jython and IronPython, and any other
platforms that don't have the concept of file descriptor tables: thus it
prevents WSGI applications from returning file-like objects on these
The requirement, as is, can only work on platforms that use file
descriptor tables, i.e. where every process has an array of open
files/file-likes, where the "fileno()" is an integer index into that
table. Granted, all *nixes, Windows, MacOS, etc, etc, all have
per-process file descriptor tables, thus belying their C/unix heritage.
Neither jython nor ironpython have file descriptor tables. Since the
concept of file descriptor tables is platform specific, both the JVM and
the .Net CLR eliminated them, and modelled all file-like objects as
specific object classes, e.g. java.io.OutputStream,
java.nio.SelectableChannel, System.IO.*, etc. If you want to create a
file-like object, you must use one of platform-supplied classes: there
is no global table of such file-like objects. You can no longer pass
around "file descriptors", i.e. indexes into a table of file objects,
because the semantics of what you can with various file-like objects
varies between those objects.
Some pythonistas don't like this object specialization for file-like
objects, and prefer the *nix file descriptor approach, since it is
comparable to python's late-binding approach to datatypes. However, lack
of file descriptor tables is an unavoidable reality on the JVM and CLR:
the two most widespread virtual-machines in the world.
Insisting on the "fileno()" method returning a file descriptor makes it
impossible to return a file like object to a jython or ironpython
implemented WSGI container.
IMHO, the correct approach is for the appplication to return an actual
file-like object, e.g. one with a read() method, and for the
server/framework to then map that file-like object to whatever
high-performance byte-stream-type object is appropriate on the platform.
On java, for example, this could be a java.nio.FileChannel. Once one of
these had been obtained from the returned file-like object, the high
performance FileChannel.transferTo() could then be used to transfer the
file contents to the socket return stream.
So, please can we have WSGI require the return of a file-like object,
which the WSGI server/framework is then free to map to a
high-performance channel in whatever way is appropriate?
The "must return a file descriptor approach" is broken.
More information about the Web-SIG