[Web-SIG] Pending modifications to PEP 333

[Alan Kennedy]

[Phillip J. Eby]
 > I'm just about to check in a major update to the PEP, per the details
 > below.

Phillip,

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 
platforms.

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.

http://java.sun.com/j2se/1.4.2/docs/api/java/nio/channels/FileChannel.html#transferTo(long,%20long,%20java.nio.channels.WritableByteChannel)

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.

Kind regards,

Alan.