Take the 2-minute tour ×

I've finally concluded that I can no longer afford to just hope the ongoing Py3k/WSGI disasterissues will be resolved anytime soon, so I need to get ready to move on.

Unfortunately, my available options don't seem a whole lot better:

  • While I find a few different Python modules for FastCGI scattered around the web, none of them seem to be getting much (if any) attention and/or maintenance, particularly with regard to Python 3.x, and it's difficult to distinguish which, if any, are really viable.
  • Falling all the way back to the built-in CGI module is hardly better than building something myself from scratch (worse, there's an important bug or two in there that may not get attention until Python 3.3).
  • There is no higher sin than handling HTTP directly in a production webapp. And anyway, that's still reinventing the wheel.

Surely somebody out there is deploying webapps on 3.x in production. What gateway interface are you using, with which module/libraries, and why?

share|improve this question
I'm not aware of any of the big names (Django, Twisted, Zope) that have Python 3 ports yet, but this is certainly a useful question –  Wayne Werner Aug 13 '10 at 13:25
@Wayne: Well, I say "web apps", but what I'm currently focused on is really a subset thereof: web-based APIs (specifically SOAP on current project, ick). So I have less dependence on large third-party frameworks, and my current code is right down at the WSGI layer. –  Nicholas Knight Aug 13 '10 at 13:32
Well, I've not used Python3 with WSGI so I'm not familiar with the problems you allude to. Is there any good (aside from just wanting to be an early adopter) reason to be using Python3 for this? –  Wayne Werner Aug 13 '10 at 13:52
@Wayne: 2.7 in the last major 2.x release. The branch is dead, and writing new code likely to live for years if not decades that depends on it is silly. Meanwhile, 3.x actually tries to do Unicode right, has plenty of make-life-easier features, has a far better-normalized standard library, is the new target for the Unladen Swallow and other performance work, and if we ever get the GIL out of CPython, that's where it'll disappear. And I don't really consider almost two years after release to be "early adopter". :) –  Nicholas Knight Aug 13 '10 at 14:13
@Nicholas: Well, you can use from __future__ imports that will at least help keep conversions easy. I actually asked a question about that. And you're right about early adoption - although my semantics were referring to the number of packages that have not yet been ported to 3.x (most of them). –  Wayne Werner Aug 13 '10 at 17:15

2 Answers 2

CherryPy 3.2 release candidates support Python 3.X. Because it only supports WSGI at the web server interface layer and not through the whole stack, then you are isolated from issues as to whether WSGI will change. CherryPy has its own internal WSGI server, but also can run under Apache/mod_wsgi with Python 3.1+. See:

http://www.cherrypy.org/wiki/WhatsNewIn32 http://code.google.com/p/modwsgi/wiki/SupportForPython3X

share|improve this answer
I have all the respect in the world for you, Graham, but this answer basically suggests I add a dependency on a pre-release version of a complex framework for which I have no use other than "insulating" myself from WSGI (which is something I shouldn't have needed in the first place). That's highly unsatisfying. Considering the lack of other answers, adopting/porting one of the FastCGI wrappers and maintaining it myself seems to be the most business-viable option at this point. :( –  Nicholas Knight Aug 14 '10 at 13:05
I am just giving you options as you asked. If you look at CherryPy documentation page for that version it also mentions it's improved FASTCGI support. The way I read that, is it has it's own FASTCGI adapter for WSGI and that may well also run on Python 3.X as well. As it stands, CherryPy is the only significant framework that is trying to find a way to run on Pyyhon 3.X so surely something can be learnt from it. The only other Python framework I know that claims to work on Python 3.X is Bottle, but it only works on WSGI and so dependent on Apache/mod_wsgi. –  Graham Dumpleton Aug 14 '10 at 20:33
I agree with Graham and many of the other commenters here: 1. If you're rolling with Python 3, you're an early adopter. 2. CherryPy is a good solution. 3. People shouldn't be writing non-framework Python for web apps. Only the frameworks should be entirely at the WSGI level. –  Adam Nelson Aug 18 '10 at 21:14
@Adam: 1) Two years. If that were so early adopter that the Python community truly viewed "can't do web development yet" as reasonable, Python 3 would be doomed. 2) CherryPy is a solution to a problem that I don't have -- or wouldn't, if websig had managed after two long years to standardize WSGI for Py3k. 3) My app gains nothing from a third-party framework beyond compensating for the failure to get a WSGI 1.1 out there. 4) Telling me to write a "micro-framework" for a standard that doesn't exist is not helpful, it just reinforces my view that targeting FastCGI is the only sane choice. ... –  Nicholas Knight Aug 19 '10 at 23:56
@Adam: ... 5) What if I were a framework developer? What would your answer then be? Don't write a new framework? Again, that would be a solution to an unasked question. 6) You and Graham have both missed the key point of this question: What are people using in production today. I still don't have an answer to that from anyone. Leading to either "do it myself" or "ignore Python 3 as irrelevant". The latter would be stupid, the former just costs a little more time. –  Nicholas Knight Aug 19 '10 at 23:57

bottle supports Python 3, but it suffers from the broken stdlib. However, multipart reimplements cgi.FieldStorage and can be used with bottle to build a Python 3 WSGI web app. I just published a demo. For the moment it is just a test, but as far as I can tell it works well.

share|improve this answer

Your Answer


