[Web-SIG] Request for Comments on upcoming WSGI Changes

[Graham Dumpleton]

2009/9/21 René Dudfield <renesd at gmail.com>:
> On Mon, Sep 21, 2009 at 9:46 AM, Georg Brandl <g.brandl at gmx.net> wrote:
>> René Dudfield schrieb:
>>> On Mon, Sep 21, 2009 at 8:10 AM, Chris McDonough <chrism-ccARneWBNkgAvxtiuMwx3w at public.gmane.org> wrote:
>>>>
>>>> OTOH, I suspect the Python 3 stdlib is still broken if it requires native
>>>> strings in various places (and prohibits the use of bytes).
>>>
>>> yes, python3 stdlib should support 'str'(the old unicode), 'buffer'
>>> and 'bytes' for web using stuff.  Buffer is important because it's a
>>> type also used for sockets(along with bytes) and it allows less memory
>>> allocation (because you can reuse buffers).
>>
>> Please don't confuse readers and use the correct name, i.e. 'bytearray'
>> instead of 'buffer'.
>>
>> Georg
>>
>
> Let me try and reduce the confusion...
>
> There are two different python types the py3k socket module uses:
> 'bytes' and 'buffer'.  'bytes' is kind of like str in python3... but
> with reduced functionality (no formatting, less methods etc).  buffer
> is a Py_buffer from the c api.
>
> buffer, and bytes in socket:
> http://docs.python.org/3.1/library/socket.html#socket.socket.recvfrom_into
> bytearray: http://docs.python.org/3.1/library/functions.html#bytearray
> bytes: http://docs.python.org/3.1/library/functions.html#bytes
> buffer: http://docs.python.org/3.1/c-api/buffer.html
>
> This is separate, but related to the point of bytes vs unicode.  It is
> really (bytes and buffer) vs unicode - since bytes and buffer can be
> used with socket.  socket never uses a python2 'unicode', or a python3
> 'str' type.

A WSGI adapter need not be sitting on top of a socket, it may be based
on some lower level API which provides an abstract interface to the
client connection. For example, in Apache the code handling a request
doesn't deal with the socket. As such, requiring buffer/bytearray
would likely stop you from using any embedded system within a web
server, such as is the case for Apache/mod_wsgi. I would suspect that
requiring buffer/bytearray would also prevent WSGI being used on top
of CGI as well as file objects don't likely deal in those types
either.

I would also suggest that pursuing these types is just a case of
premature optimisation. Where is your proof that using them would give
any benefit? The web server layer is never the bottleneck in a web
stack, it is the web application, its routing and rendering systems
and any interaction with a database that are the bottleneck. It would
be a waste of time to overly complicate the WSGI specification for
absolutely no reason. People could get much better performance by
simply paying attention to their own web applications and making them
run better rather than praying that the underlying server is somehow
going to make their application 4 times faster than anything else
around.

Maybe we can call this rush to prematurely optimise or jump on the
bandwagon of the latest asynchronous server Tornado syndrome. ;-)

Graham