[Web-SIG] WSGI for Python 3

Graham Dumpleton graham.dumpleton at gmail.com
Tue Jul 20 06:37:03 CEST 2010


On 19 July 2010 03:19, P.J. Eby <pje at telecommunity.com> wrote:
> At 01:01 PM 7/18/2010 +1000, Graham Dumpleton wrote:
>>
>> This is on the basis that if people are going to have to rewrite their
>> code
>> a fair bit to handle bytes everywhere,
>
> What you mean by "rewrite their code a fair bit", and who is it that you
> think will have to do this?
> Or, more precisely, how is that any different from the text or
> text-and-bytes proposals?

My comments are based on the mood I have got from listening to
discussions here on this list and discussions in other forums and irc
channels. To me there appears to be a tendency towards people thinking
that having bytes everywhere will be harder to deal with than the text
proposal.

> AFAICT, the main difference is that under a
> bytes-only regime, the changes should be more consistent/mechanical, i.e.,
> able to be performed by relatively superficial code inspection.

The problem in all these discussions is that practically no one has
been prepared to actually sit down and attempt to migrate any
significant code over to any of these proposals and Python 3.0.

The only notable attempt is the work Robert Brewer did with CherryPy.
Ultimately though I don't think the CherryPy case tells us much as it
simple translates the interface in to an internal way of doing things.
The true litmus test will be the conversion of any framework which
keeps the WSGI interface exposed, with it being used as a means of
composing together components to make a stack.

Until someone has done that we have absolutely no evidence one way or
the other as to what proposal is easier or even viable given potential
short comings, or otherwise, in the Python language and standard
libraries.

It is a chicken and egg problem though in that I would say practically
everyone doesn't want to do anything until the WSGI specification has
been updated as they don't want to waste their time. You cant though
update the specification without truly knowing whether a particular
approach will work and to do that you have no choice but to actually
try it.

And before you argue that the hosting mechanisms haven't been there to
do that I will point out that mod_wsgi specifically implemented a way
of being able to selectively say whether bytes or text was passed
through. That code for bytes support sat there for six months or more
and there was zero interest expressed to me by anyone in using it as a
basis of some actual attempts at migrating existing code as a test. In
the end it got thrown out due to that lack of interest and due to it
holding up a new release of mod_wsgi.

Distinct from mod_wsgi, it also wouldn't be that hard for interested
people to modify wsgiref to implement the different proposals. I
stress again that no one seems prepared to do that and again even if
it was done, who is then going to try and use it.

Thus we all just sit here on the fence waiting for others to do
something, pushing our particular ideas and occasionally flip flopping
between those ideas as well.

Finally and for the record, I will not be modifying mod_wsgi to change
it in anyway now until I see a separate proof of concept WSGI server
and a decent sized framework ported to it. So yes I am going to sit on
the fence as well, but that is because I have been burned in the past
in putting in effort on this only see it go now where. I am not going
to waste my time again like that.

Graham


More information about the Web-SIG mailing list