Web gateway interfaces in Python 3.

views:

1553

answers:

+19 Q:

Web gateway interfaces in Python 3.

I've finally concluded that I can no longer afford to just hope the ongoing Py3k/WSGI ~~disaster~~issues 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?

+1 A:

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

Graham Dumpleton 2010-08-14 02:26:40

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 2010-08-14 13:05:02

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 2010-08-14 20:33:56

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 2010-08-18 21:14:19

With that said though, maybe you should write your own micro-framework that works with wsgi and Python3, or modify one of the existing ones accordingly? http://wiki.python.org/moin/WebFrameworks

Adam Nelson 2010-08-18 21:21:32

@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 2010-08-19 23:56:18

@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 2010-08-19 23:57:16

One of the primary reasons that WSGI on Python 3.X has not progressed, is because people would not get off their butts and actually try to use the Python 3.X support that was added into mod_wsgi, well over a year ago, as a test bed to determine what would work and whether anything needed to change. Instead pretty well everyone just sat on the fence waiting for everyone else to go and do something. Those few people who did actually put in some effort to work out the issues had to endure a constant bombardment of unhelpful comments, usually criticism, from those same fence sitters.

Graham Dumpleton 2010-08-20 04:40:35

Ultimately a lot of the problems don't even come down to the WSGI interface, as by itself how WSGI is being implemented on Python 3.X by mod_wsgi and wsgiref is as serviceable as WSGI on Python 2.X. The real problems lie in the Python standard library and various modules within it that don't deal with bytes very well. There is even some argument that the Python language object model itself needs to change by virtue of introduction of a new string like bytes type to make web applications practical to implement. So WSGI shouldn't necessarily be the target, as there are bigger issues to sort out.

Graham Dumpleton 2010-08-20 04:51:12

For the record, this is the first time I've made any comments about Python 3.x + WSGI, and I haven't "gotten off my butt" and actually tried it because _everything_ you and others have written says to me "danger! danger! stay away!". If you had a good, coherent strategy for doing WSGI in Python 3 and wanted people to try working with it, _saying that_, preferably with a draft PEP to accompany it, would certainly have gotten _my_ attention. From my outsider perspective, all I've seen is periodic websig bickering and mod_wsgi "support" that sounds tentative at best, again screaming "stay away!".

Nicholas Knight 2010-08-20 07:27:45

Put simply, I was waiting for the experts (e.g. you) to tell me what I should be doing (or at least trying), but nothing I'd seen before now has ever indicated what I should be doing or trying. Everything talks about a "de-facto definition" (which I've not seen beyond the list of "key points" in the mod_wsgi doc) or experimental support or just plain "it's not ready yet". That told me I should be waiting for you if I didn't want to waste my time -- not that you needed my help to get to the finish line.

Nicholas Knight 2010-08-20 07:31:56

Don't hold your breath waiting for me to do anything more, I already tried many times in the past to direct people what to do, including making available code as a proof of concept for people to use. That code still exists and still can be used. If I were to rename it something else it would be just as valid as another solution to handle web applications on Python 3.X. People now are too hung up on the WSGI name though and if they don't think it is the official WSGI will not use it. As a result, it is probably better at this point that I just rip the Python 3.X support out of mod_wsgi.

Graham Dumpleton 2010-08-20 09:34:37

@Graham: Please don't rip out the Python 3.X support from mod_wsgi! I've just started a new Python 3 project built on mod_wsgi (alas, without any web framework) and I, for one, appreciate all the effort that was put into making "Python 3" and "WSGI" not mutually incompatible terms.

Cameron 2010-09-20 21:15:07

+1 A:

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.

wobsta 2010-08-26 22:40:14

ansaurus

tags:

views:

answers:

Web gateway interfaces in Python 3.

related questions