Tuesday, April 28, 2009

Python 3.0 support in mod_wsgi to be disabled.

I have been hanging off releasing mod_wsgi3.0 due to uncertainties in how WSGI 1.0 specification should be implemented in Python 3.0. Despite a number of discussions on Python WEB-SIG about it, there has never really been any final consensus on the issue. This isn't helped one bit by the fact there is no formal process for agreeing, by way of vote or otherwise, on changes or amendments to the WSGI specification. Thus, all the conversation just amounts to a lot of hot air at the end of the day as nothing ever gets agreed upon.

As a result, I am going to move ahead with releasing mod_wsgi 3.0, but am going to disable support for Python 3.0. I will not remove the code entirely, but will make it necessary to go through some hoops to allow you to build mod_wsgi with Python 3.0, with suitable large disclaimers that if you use what is there, you will likely have to change your code at a future date when any amendments are agreed upon. In the mean time I will not be supporting the code related to Python 3.0.

It has come to this as it appears that other WSGI adapters attempting to support Python 3.0 are not implementing it the same way. This isn't a complaint against the authors of those other WSGI adapters as they are in the same boat as I am. The real problem is that there is no WSGI specification which covers Python 3.0. It is already bad enough that the WSGI 1.0 specification has various areas that aren't well defined or which are too restricting, to the extent that many of the major frameworks possibly don't even adhere to it. So, one can see this as being my protest at the lack of any formal processes for the development of the WSGI specification.

And before you have a go at me and say then that I should instigate such a formal process, let it be known that I have tried that already and there was no interest. So called consensus was that consensus was sufficient.

Some have suggested to me that I would be effectively setting the standard with what ever I released in mod_wsgi. Well, I don't want that to be the case. Although I wrote mod_wsgi I don't write web applications myself and am not across all the nuances of what would or wouldn't work for Python 3.0. Thus, I rely on the experience of others in helping define what the WSGI specification should be and merely implement that specification. So, no specification, no support.

I think you're doing the right thing. Perhaps your move will encourage the use of proper process. If you design code based on the "consensus" of the people who are capable of emitting the most hot air, then you might as well be working on PHP. ;-)

@István: Part of the problem is that I don't believe the range of input is there. Comment is only coming from people associated with a small selection of the major Python web frameworks and applications. Thus it is hard to know whether the others just don't care or don't know. I'd prefer to know the stance of all the major players. Maybe it is too premature for this since they don't even have Python 3.0 on the radar as yet.

@nnis: Once you put something out there you cannot take it back. So, if something is too accommodating and then you restrict it later, you just cause a lot of pain. Some of the issues are also rather fundamental and aren't just a case of whether you allow something or not, but how you actually do it.

@illume: Not all discussion has been on the WEB-SIG list. For whatever reason, email to the list for at least one person whose opinion I respect, has been disappearing into some SPAM black hole and so they have not been able to readily join the conversation.

Anyway, the two major issues outstanding are, whether WSGI adapter should accept string output or only bytes. Understand that Robert in CherryPy WSGI server is at the moment only allowing bytes. The much more hairy one and which has caused most of the discussion is whether variables in WSGI environment source from CGI environment equivalents, should be bytes or strings. Even though there was a leaning to them being strings, there was still some reservations on that issue, both on and off the list. I think there was enough issues with RFC 2047 that seen that WSGI adapters shouldn't bother with that.