I've just pushed the first working release of Fapws with Python3 ;-).
(branch called python3)
Because of changes made in PYthon3, lot of internal codes have change.
The only test/sample currently working is the one present in
With the simple "Hello World!!" sample, I observe a decrease of +-5%
of the performance (on a linux server, thus with epoll): 5675#/sec
with python-3.2 and 5951 with python-2.7.
It's rather difficult to say if this delta is coming from python or
from my changes in Fapws. Most probably the unicode - bytes conversion
cost the most.
After this rather long and complex dive into the new PYthon language
(python3 is so much different than python2); I must say that I find
the concept of bytes is very well welcome and avoid some weird side
effects. But unfortunately the change in Python3.2 are not limited to
But the most tricky part is concerning the WSGI rules it self ??!!!???
Indeed everybody has his own interpretation of how wsgi-1.0 must evolve ;-(.
Just look at this page to see the different interpretations:
Currently implemented in fapws is the "wsgi-1.0"; in other words all
old-string elements have been converted to bytes.
For the Wsgi developpers this means that "environ" and
"start_response" must be fully in bytes (keys and values).
I don't know if this is the best approach ;-(.
Let me know what you think and let's have a discussion.
Checkout the python3 release of the code to test it.
other samples must still be translated to python3 ;-(.
PEP 3333 has been accepted as the official way to do WSGI with Python 3
months ago by Guido van Rossum. So no need to worry about multiple
Is there a simple summary table around ?
Up to know I've implemented the rule saying that every py2-string
should be py3-bytes.
It's pretty simple actually. Use native strings for environ keys and
values and bytes for `wsgi.input` and the result iterator -- in short,
bytestrings for "bodies" and native strings for everything else.