At 08:06 PM 9/18/2009 +1000, Graham Dumpleton wrote:
> Sometimes clients calling the wsgi code will be
> buggy... and looking at the unquoted url is needed in those cases to
> work around buggy clients.
Bugs in WSGI adapters aren't a good reason for why it is needed. If
the WSGI adapters are bro
At 02:08 AM 9/19/2009 +0200, Armin Ronacher wrote:
greenlets are one solution, but I don't think there are any applications
out there using write() that are worth supporting in WSGI 2.0. Such
applications should rather use an internal buffer and write to that.
If an internal buffer was suitabl
At 06:58 PM 9/18/2009 -0500, Ian Bicking wrote:
What's wrong with this simpler approach to the conversion?
It's not compliant with the WSGI 1 spec, which calls for write() to
be unbuffered.
On the one hand, you could say that anybody who gives a crap about
the spec wouldn't use write() to b
On Fri, Sep 18, 2009 at 7:09 PM, Armin Ronacher
wrote:
> Ian Bicking schrieb:
>> What's wrong with this simpler approach to the conversion?
> It buffers, you can no longer do this:
>
> request.write('processing data')
> request.flush()
> ...
> request.write('data processed')
> request.fl
Hi,
Ian Bicking schrieb:
> What's wrong with this simpler approach to the conversion?
It buffers, you can no longer do this:
request.write('processing data')
request.flush()
...
request.write('data processed')
request.flush()
But that's not too common and people should rather rewr
Hi,
P.J. Eby schrieb:
> newer spec. On CPython at least, this can be implemented using
> greenlets, and on other Python implementations it could be done with
> threads. Here's a quick and dirty, untested sketch (no error
> checking, no version handling) of how it could be done with greenlets:
On Fri, Sep 18, 2009 at 5:07 PM, P.J. Eby wrote:
> On his blog, Graham mentioned some skepticism about skipping WSGI 1.1 and
> going straight to 2.0, due to concern that people using write() would need
> to make major code changes to go to WSGI 2.0.
I'm not entirely clear why this is such a big d
On his blog, Graham mentioned some skepticism about skipping WSGI 1.1
and going straight to 2.0, due to concern that people using write()
would need to make major code changes to go to WSGI 2.0.
Now, if we ignore the part of the spec that says "New WSGI
applications and frameworks *should not*
Hi,
René Dudfield schrieb:
> Perhaps a good way to test that, is to make a smallish example wsgi
> program to port to python3, using the various proposals... or the
> proposal most liked.
Not a good idea. Because a small WSGI application directly on top of
WSGI behaves completely different than a
On Fri, Sep 18, 2009 at 12:03 PM, Armin Ronacher
wrote:
>> It looks like python3 issues are being addressed in your changes anyway.
> But it should be discussed separately and then be integrated. The
> changes in the PEP currently reflect #1 of Graham's proposal.
>
yeah cool. Here's a new threa
On Fri, Sep 18, 2009 at 2:56 AM, Graham Dumpleton
wrote:
> As others have pointed out, the likes of rack and jack, not sure about
> the new Perl variant, don't seem to have an issue with using unicode.
I looked up Jack and Rack: http://jackjs.org/jsgi-spec.html and
http://rack.rubyforge.org/doc/f
Hi,
Let me backup a bit here.
We have to focus on two difference use cases for WSGI on Python 3. The
one is the application that should continue to work on Python 3, the
other one is the application that was designed for Python 3.
In both cases let's just assume that this application is using
W
Hi,
Graham Dumpleton schrieb:
> On top of the issues above, Armin believes 2to3 gives better results
> where bytes everywhere interpretation is used. Has anyone else
> actually tried 2to3 and have the experience with it?
You slightly misquoted me. I said that 2to3 gives good results on high
level
2009/9/18 René Dudfield :
> On Fri, Sep 18, 2009 at 11:21 AM, Graham Dumpleton
> wrote:
>> 2009/9/18 Benoit Chesneau :
>>> And sometimes you need to support full uri spec. For example %2F is
>>> different from / . Actually if all url is decoded you don't know if the
>>> client request was %2F or /
[Rene]
>> I think you mean pre-2.2 support, not python 2.2? iterators came
>> about in python 2.2.
[Armin]
> That might be. That was before my time. I'm pretty sure the first
> Python version I used was 2.3, but don't quote me on that.
As WSGI was being developed, cpython was at version 2.3.
On Fri, Sep 18, 2009 at 11:21 AM, Graham Dumpleton
wrote:
> 2009/9/18 Benoit Chesneau :
>> And sometimes you need to support full uri spec. For example %2F is
>> different from / . Actually if all url is decoded you don't know if the
>> client request was %2F or /, you just get a /. Which is annoy
Hi,
Graham Dumpleton schrieb:
> I believe it does matter and that it contains ASCII possibly doesn't
> mean it is somehow simpler. The reason is that URL reconstruction
> recipe as per WSGI PEP has to work. Ie.
> *snip*
That of course will not work and is not something we should aim for.
There is
Hi,
René Dudfield schrieb:
> It says "Because of this future revisions of WSGI will most likely
> switch away from a raw CGI environment to require the server to
> provide these values to be quoted and available on a different key."
This information would be additional information of course!
> Al
2009/9/18 Armin Ronacher :
> Hi,
>
> For this topic I would love to remember everybody that the web is
> currently changing and will even more change in the future which will
> probably also mean that a lot of what we're doing currently might not be
> common practise in the near future.
>
> WSGI is
2009/9/18 Benoit Chesneau :
> And sometimes you need to support full uri spec. For example %2F is
> different from / . Actually if all url is decoded you don't know if the
> client request was %2F or /, you just get a /. Which is annoying. It causes
> some problem with some api ,I'm thinking to co
2009/9/18 René Dudfield :
> On Fri, Sep 18, 2009 at 8:56 AM, Graham Dumpleton
> wrote:
>>> The big problems are always PATH_INFO and SCRIPT_NAME. Those are the
>>> only values that are in the dict URL-decoded and might contain non-ASCII
>>> characters. (except for headers, but that's a different
On Sep 18, 2009, at 10:12 AM, René Dudfield wrote:
Why is the raw url needed(very rarely)?
Sometimes there are bugs. Access to the raw string lets you work
around those bugs... if you need to. Dropping to a lower level is
needed sometimes.
Some APIs require you to send back an exact copy of
On Fri, Sep 18, 2009 at 8:56 AM, Graham Dumpleton
wrote:
>> The big problems are always PATH_INFO and SCRIPT_NAME. Those are the
>> only values that are in the dict URL-decoded and might contain non-ASCII
>> characters. (except for headers, but that's a different story because
>> the only real-wo
2009/9/18 Armin Ronacher :
> Hi,
>
> Graham currently proposes[1] the following behaviors for Strings in WSGI
> (Python version independent). However this mail only covers the Python
> 3 part which I assume becomes a separate section in the PEP or even WSGI
> version.
>
> Terminology:
>
> byte st
I'm pretty sure you can use async sockets + wsgi with Eventlet.
http://eventlet.net/
That shows it's possible to support wsgi with async servers. Eventlet
is quite nice towards wsgi in this way.
One of eventlets backends is twisted.
___
Web-SIG mailing
2009/9/18 Armin Ronacher :
> Hi,
>
> This is my first reply in a list of replies for Grahams lengthy blog
> post about WSGI 3 [1]. I break it up into multiple separate threads so
> that this can be discussed easier.
>
>> What should be highlighted is that for Jython, as I understand it at
>> least
2009/9/18 Armin Ronacher :
> Hi,
>
> Graham mentioned that the WSGI development might further drift apart
> based on the changes Ian Bicking and I did on DjangoCon in a separate hg
> repository [1] for the WSGI PEP.
>
> I just want to point out that these are in no way final and are further
> inten
Hello,
On Thu, Sep 17, 2009 at 10:48 PM, Armin Ronacher
wrote:
> Hi,
>
> René Dudfield schrieb:
>> I don't like yours and Ians changes with regard to cgi. cgi exists.
>> Breaking wsgi apps on cgi is silly.
> Can you give an example on where we break CGI compatibility?
>
>From this link: http:/
28 matches
Mail list logo
