<br><br><div class="gmail_quote">On Mon, Sep 21, 2009 at 11:30 AM, Graham Dumpleton <span dir="ltr">&lt;<a href="mailto:graham.dumpleton@gmail.com">graham.dumpleton@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
2009/9/21 René Dudfield &lt;<a href="mailto:renesd@gmail.com">renesd@gmail.com</a>&gt;:<br>
<div><div></div><div class="h5">&gt; On Mon, Sep 21, 2009 at 9:46 AM, Georg Brandl &lt;<a href="mailto:g.brandl@gmx.net">g.brandl@gmx.net</a>&gt; wrote:<br>
&gt;&gt; René Dudfield schrieb:<br>
&gt;&gt;&gt; On Mon, Sep 21, 2009 at 8:10 AM, Chris McDonough &lt;<a href="mailto:chrism-ccARneWBNkgAvxtiuMwx3w@public.gmane.org">chrism-ccARneWBNkgAvxtiuMwx3w@public.gmane.org</a>&gt; wrote:<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; OTOH, I suspect the Python 3 stdlib is still broken if it requires native<br>
&gt;&gt;&gt;&gt; strings in various places (and prohibits the use of bytes).<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; yes, python3 stdlib should support &#39;str&#39;(the old unicode), &#39;buffer&#39;<br>
&gt;&gt;&gt; and &#39;bytes&#39; for web using stuff.  Buffer is important because it&#39;s a<br>
&gt;&gt;&gt; type also used for sockets(along with bytes) and it allows less memory<br>
&gt;&gt;&gt; allocation (because you can reuse buffers).<br>
&gt;&gt;<br>
&gt;&gt; Please don&#39;t confuse readers and use the correct name, i.e. &#39;bytearray&#39;<br>
&gt;&gt; instead of &#39;buffer&#39;.<br>
&gt;&gt;<br>
&gt;&gt; Georg<br>
&gt;&gt;<br>
&gt;<br>
&gt; Let me try and reduce the confusion...<br>
&gt;<br>
&gt; There are two different python types the py3k socket module uses:<br>
&gt; &#39;bytes&#39; and &#39;buffer&#39;.  &#39;bytes&#39; is kind of like str in python3... but<br>
&gt; with reduced functionality (no formatting, less methods etc).  buffer<br>
&gt; is a Py_buffer from the c api.<br>
&gt;<br>
&gt; buffer, and bytes in socket:<br>
&gt; <a href="http://docs.python.org/3.1/library/socket.html#socket.socket.recvfrom_into" target="_blank">http://docs.python.org/3.1/library/socket.html#socket.socket.recvfrom_into</a><br>
&gt; bytearray: <a href="http://docs.python.org/3.1/library/functions.html#bytearray" target="_blank">http://docs.python.org/3.1/library/functions.html#bytearray</a><br>
&gt; bytes: <a href="http://docs.python.org/3.1/library/functions.html#bytes" target="_blank">http://docs.python.org/3.1/library/functions.html#bytes</a><br>
&gt; buffer: <a href="http://docs.python.org/3.1/c-api/buffer.html" target="_blank">http://docs.python.org/3.1/c-api/buffer.html</a><br>
&gt;<br>
&gt; This is separate, but related to the point of bytes vs unicode.  It is<br>
&gt; really (bytes and buffer) vs unicode - since bytes and buffer can be<br>
&gt; used with socket.  socket never uses a python2 &#39;unicode&#39;, or a python3<br>
&gt; &#39;str&#39; type.<br>
<br>
</div></div>A WSGI adapter need not be sitting on top of a socket, it may be based<br>
on some lower level API which provides an abstract interface to the<br>
client connection. For example, in Apache the code handling a request<br>
doesn&#39;t deal with the socket. As such, requiring buffer/bytearray<br>
would likely stop you from using any embedded system within a web<br>
server, such as is the case for Apache/mod_wsgi. I would suspect that<br>
requiring buffer/bytearray would also prevent WSGI being used on top<br>
of CGI as well as file objects don&#39;t likely deal in those types<br>
either.<br>
<br>
I would also suggest that pursuing these types is just a case of<br>
premature optimisation. Where is your proof that using them would give<br>
any benefit? The web server layer is never the bottleneck in a web<br>
stack, it is the web application, its routing and rendering systems<br>
and any interaction with a database that are the bottleneck. It would<br>
be a waste of time to overly complicate the WSGI specification for<br>
absolutely no reason. People could get much better performance by<br>
simply paying attention to their own web applications and making them<br>
run better rather than praying that the underlying server is somehow<br>
going to make their application 4 times faster than anything else<br>
around.<br>
<br>
Maybe we can call this rush to prematurely optimise or jump on the<br>
bandwagon of the latest asynchronous server Tornado syndrome. ;-)<br>
<font color="#888888"><br>
Graham<br>
</font></blockquote></div><br><br>hi,<br><br><br>Below are the reasons why I think considering buffers for a future post-wsgi-1.1 spec is useful.  I don&#39;t think it should be considered for a
wsgi 1.1 - I&#39;m now in agreement with Robert that a wsgi 1.1 should come out
very soon.  My specific concern is that pythons stdlib also support &#39;buffer&#39; (along with &#39;bytes&#39; and &#39;str&#39;) - but that is separate from the new wsgi 1.1 spec discussion. <br>
<br><br><br>---<br>I don&#39;t think *requiring* the use of buffers is needed... just making it *possible* to use them.<br>
<br>buffer is one of the types that socket supports, so it makes sense to at least consider them.<br><br>Using buffer would in no way make it impossible to use python in embedded webservers.  You can easily make a Py_buffer from the same memory apache gives you to create python strings.  In fact buffers allow you to support more embedded systems more easily - since strings are immutable, but not all embedded systems give you immutable data.  Py_buffer also supports things like strides, non-contiguous memory, read/write information and other stuff which make it possible to use more types of memory.  It&#39;s a lot more useful to use for python embedded in things than a string type.<br>
<br>This is not just about performance, it&#39;s about considering the types used these days.  One of the things that has changed since wsgi 1.0 came out is that python2.5 and above allow the use of a buffer with sockets.  Python3 also changes the types to (str, buffer).  mmap is also a very easy way to share data between multiple python processes - using the Py_buffer allows you to use mmap too.<br>
<br><br>Not all applications are the same, and some do require lots of
performance.<br><br>My use case is video over the network for requiring buffers.  When doing 100s of megabytes or gigabytes per second on one machine: copying, and allocating strings is a waste of time.  Even allocating, and copying 200KB jpeg images is a big waste of time.  It&#39;s basic programing optimization knowledge that allocating, and copying memory is slow.  So is converting memory to various different encodings if it&#39;s not needed.  Proof is by timing a string allocation + copy + transcode verses just using the buffer given.  By having the server require allocating memory, require copying memory or require transcoding the memory - that&#39;s makes my use case a lot slower than it needs to be.<br>
<br><br><br>cheers,<br>