On Tue, Jul 20, 2010 at 12:37 AM, Graham Dumpleton <graham.dumple...@gmail.com> wrote: > On 19 July 2010 03:19, P.J. Eby <p...@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 > _______________________________________________ > Web-SIG mailing list > Web-SIG@python.org > Web SIG: http://www.python.org/sigs/web-sig > Unsubscribe: > http://mail.python.org/mailman/options/web-sig/paul.joseph.davis%40gmail.com >
Just a quick note. I've started working on a project to try and get a version of wsgi running on 2.x and 3.x. I've been needing a reason to start using 3.1 for sometime and this thread has managed to spur me into action. To be clear, I'm coming at this from the point of view that as long as there are breaking changes, I might as well make things really broken. So I'll be incorporating ideas from [1] as well as other bits of trivia I've picked up. I realize this will lower the probability that anything comes of this work, but I reckon it'll at least be some code to discuss. My current plan is to get a reference implementation with some tests that runs on 2.x and 3.x. Once I get there I'll try porting WebOb [2] and maybe Django [3] (depending on the progress of its port [4]). If I get that far I'll probably make a fork of Gunicorn [5] so that there's a whole stack that runs on both 2.x and 3.x. Optimistically, I'd like to have enough code to show the reference implementation and tests by this weekend. Although, I'm still learning 3.x differences and work arounds so I could fail miserably. Paul J. Davis [1] http://wsgi.org/wsgi/WSGI_2.0 [2] http://pythonpaste.org/webob/ [3] http://www.djangoproject.com/ [4] http://wiki.python.org/moin/PortingDjangoTo3k [5] http://gunicorn.org _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
