2009/9/21 René Dudfield <ren...@gmail.com>: > On Mon, Sep 21, 2009 at 9:46 AM, Georg Brandl <g.bra...@gmx.net> wrote: >> René Dudfield schrieb: >>> On Mon, Sep 21, 2009 at 8:10 AM, Chris McDonough >>> <chrism-ccarnewbnkgavxtiumw...@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 _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
