At 02:02 PM 4/15/2011 -0400, Jim Fulton wrote:
On Fri, Apr 15, 2011 at 1:32 PM, Éric Araujo mer...@netwok.org wrote:
As an aside, I wonder why people use dot+colon notation instead of just
dots to reference callables. In distutils2 for example we resolve
dotted names to find command classes,
At 04:11 PM 4/15/2011 -0400, Fred Drake wrote:
These end users don't really care if the object identified is a class or
function in module, a nested attribute on a class, or anything else, so
long as it does what it's advertised to do. By not pushing implementation
details into the identifier,
At 09:45 AM 1/20/2011 -0500, James Y Knight wrote:
But I agree, a clarification could be added to the statement '''all
objects referred to in this specification as strings must be of
type str or StringType''' and '''For values referred to in this
specification as bytestrings [...] the value
At 02:52 PM 1/12/2011 -0800, Guido van Rossum wrote:
On Wed, Jan 12, 2011 at 2:34 PM, Alice BevanMcGregor
al...@gothcandy.com wrote:
On 2011-01-10 13:12:57 -0800, Guido van Rossum said:
Ok, now that we've had a week of back and forth about this, let me repeat
my threat. Unless more concerns
At 09:11 PM 1/10/2011 -0600, Timothy Farrell wrote:
PJ,
You seem to be old-hat at this so I'm looking for a little advise as
I draft this spec. It seems a bad idea to me to just say
environ['wsgi.executor'] will be a wrapped futures executor because
the api handled by the executor can and
At 04:39 PM 1/9/2011 -0800, Alice BevanMcGregor wrote:
On 2011-01-09 09:26:19 -0800, P.J. Eby said:
If wsgi.input offers any synchronous methods...
Regardless of whether or not wsgi.input is implemented in an async
way, wrap it in a future and eventually get around to yielding
it. Problem
At 05:06 PM 1/9/2011 -0800, Alice BevanMcGregor wrote:
On 2011-01-09 09:03:38 -0800, P.J. Eby said:
Hm. I'm not sure if I like that. The typical app developer really
shouldn't be yielding multiple body strings in the first place.
Wait; what? So you want the app developer to load a 40MB
At 06:06 AM 1/9/2011 +0200, Alex Grönholm wrote:
A new feature here is that the application itself yields a (status,
headers) tuple and then chunks of the body (or futures).
Hm. I'm not sure if I like that. The typical app developer really
shouldn't be yielding multiple body strings in the
At 04:25 AM 1/9/2011 -0800, Alice BevanMcGregor wrote:
On 2011-01-08 13:16:52 -0800, P.J. Eby said:
In the limit case, it appears that any WSGI 1 server could provide
an (emulated) async WSGI2 implementation, simply by wrapping WSGI2
apps with a finished version of the decorator in my sketch
I made a few errors in that massive post...
At 12:00 PM 1/8/2011 -0500, P.J. Eby wrote:
My major concern about the approach is still that it requires a fair
amount of overhead on the part of both app developers and middleware
developers, even if that overhead mostly consists of importing
At 05:39 AM 1/8/2011 -0800, Alice BevanMcGregor wrote:
As a quick note, this proposal would signifigantly benefit from the
simplified syntax offered by PEP 380 (Syntax for Delegating to a
Subgenerator) [1] and possibly PEP 3152 (Cofunctions) [2]. The
former simplifies delegation and
At 01:24 PM 1/8/2011 -0500, Paul Davis wrote:
For contrast, I thought it might be beneficial to have a comparison
with an implementation that didn't use async might look like:
http://friendpaste.com/4lFbZsTpPGA9N9niyOt9PF
Compare your version with this one, that uses my revision of Alice's
At 04:40 AM 1/9/2011 +0200, Alex Grönholm wrote:
09.01.2011 04:15, Alice BevanMcGregor kirjoitti:
I hope that clearly identifies my idea on the subject. Since async
servers will /already/ be implementing their own executors, I don't
see this as too crazy.
-1 on this. Those executors are meant
At 06:15 PM 1/8/2011 -0800, Alice BevanMcGregor wrote:
On 2011-01-08 17:22:44 -0800, Alex Grönholm said:
On 2011-01-08 13:16:52 -0800, P.J. Eby said:
I've written the sketches dealing only with PEP 3148 futures, but
sockets were also proposed, and IMO there should be simple support
At 05:00 PM 1/7/2011 +1100, Graham Dumpleton wrote:
Stupid question first. When running 2to3 on the example CGI code,
Don't do that. It's supposed to already be Python 3 code. ;-)
It did, however, reveal a bug where I have not in fact done the
correct Python 3 thing:
if
At 12:39 AM 1/7/2011 -0800, Alice BevanMcGregor wrote:
Earlier in this post I illustrated a few that directly apply to a
commercial application I am currently writing. I'll elaborate:
:: Image scaling would benefit from multi-processing (spreading the
load across cores). Also, only one
At 01:17 AM 1/7/2011 -0800, Alice BevanMcGregor wrote:
On 2011-01-06 20:18:12 -0800, P.J. Eby said:
:: Reduction of re-implementation / NIH syndrome by
incorporatingthe most common (1%) of features most often
relegated to middlewareor functional helpers.
Note that nearly every application
At 12:37 PM 1/7/2011 -0800, Alice BevanMcGregor wrote:
But is there really any problem with providing a unified method for
indication a suspend point?
Yes: a complexity burden that is paid by the many to serve the few --
or possibly non-existent.
I still haven't seen anything that suggests
At 01:22 PM 1/7/2011 -0800, Alice BevanMcGregor wrote:
On 2011-01-07 08:28:15 -0800, P.J. Eby said:
At 01:17 AM 1/7/2011 -0800, Alice BevanMcGregor wrote:
On 2011-01-06 20:18:12 -0800, P.J. Eby said:
:: Reduction of re-implementation / NIH syndrome
byincorporatingthe most common (1
At 01:03 PM 1/6/2011 +, chris.d...@gmail.com wrote:
Does that apply here? It seems you either allow unicode strings or you
don't, not a certain subsection.
That's why PEP requires bytes instead - only the application
knows what it's sending, and the server and middleware shouldn't
At 12:52 PM 1/6/2011 -0800, Alice BevanMcGregor wrote:
Ignoring async for the moment, the goals of the PEP 444 rewrite are:
:: Clear separation of narrative from rules to be
followed. This allows developers of both servers and applications
to easily run through a confomance check list.
::
At 09:51 AM 1/7/2011 +1100, Graham Dumpleton wrote:
Is that the last thing or do I need to go spend some time and write my
own CGI/WSGI bridge for Python 3 based on my own Python 2 one I have
lying around and just do some final validation checks with a parallel
implementation as a sanity check
At 05:47 PM 1/6/2011 -0800, Alice BevanMcGregor wrote:
Tossing the idea around all day long will then, of course, be
happening regardless. Unfortunately for that particular discussion,
PEP 3148 / Futures seems to have won out in the broader scope.
Do any established async frameworks or
At 06:30 PM 1/3/2011 -0800, Guido van Rossum wrote:
Would
sys.stdout.buffer.write(b'abc')
do?
(If you mix this with writing strings to sys.stdout directly, you may
have to call sys.stdout.flush() first.)
The current code is:
sys.stdout.write(data) # TODO: this needs to be
At 12:43 PM 1/4/2011 +, Antoine Pitrou wrote:
Alice BevanMcGregor al...@... writes: [1]
http:://bit.ly/e7rtI6 So, while we are at it, could we get rid of
the CGI server example in this new SWGI spec? This is 2011, and we
should promote modern idioms, not encourage people to do 1995 Web
At 09:51 PM 1/4/2011 +1100, Graham Dumpleton wrote:
Add another point. FWIW, these are coming up because of questions
being asked on python-dev IRC channel about PEP .
The issue as it came down to was that the PEP may not be clear enough
in explaining that where str() is unicode and as such
At 08:53 PM 1/4/2011 +1100, Graham Dumpleton wrote:
BTW, to what extent are the examples in the PEP meant to be able to
work on both Python 2.X and Python 3.X as is.
Does it need to be clarified where examples will only work on Python
3.X, in particular the CGI gateway.
The intention is that
At 04:43 PM 1/3/2011 -0800, Guido van Rossum wrote:
On Mon, Jan 3, 2011 at 3:13 PM, Jacob Kaplan-Moss ja...@jacobian.org wrote:
On Sun, Jan 2, 2011 at 9:21 AM, Guido van Rossum gu...@python.org wrote:
Although [PEP ] is still marked as draft, I personally think of it
as accepted; [...]
At 08:04 PM 1/3/2011 -0500, Randy Syring wrote:
In the server/gateway example, there is a comment in the code that says:
# TODO: this needs to be binary on Py3
The TODO part confuses me. In other areas of the PEP, there are
comments like:
# call must be byte-safe on Py3
which make sense.
At 05:04 PM 1/2/2011 +1100, Graham Dumpleton wrote:
That PEP was rejected in the end and was
replaced with PEP 342 which worked quite differently, yet I cant see
that the WSGI specification was revisited in light of how it ended up
being implemented and the implications of that.
Part of my
At 12:38 PM 1/2/2011 -0800, Alice BevanMcGregor wrote:
On 2011-01-02 11:14:00 -0800, Chris McDonough said:
I'd suggest we just embrace it, adding minor tweaks as necessary,
until we reach some sort of technical impasse it doesn't address.
Async is one area that does not cover, and that
At 02:21 PM 1/2/2011 -0800, Alice BevanMcGregor wrote:
On 2011-01-02 11:57:19 -0800, P.J. Eby said:
* -1 on the key-specific encoding schemes for the various CGI
variables' values -- for continuity of coding (not to mention
simplicity) PEP 's approach to environ encodings should beused
As I've been tidying up wsgiref in the stdlib for PEP , I've been
noticing that there's a bit of an issue with the PEP as far as CGI variables.
Currently, the CGI example is the same as it is in PEP , which
means that it's correct code for Python 2.x, but wrong for 3.x due to
the
At 10:35 AM 10/22/2010 +1100, Graham Dumpleton wrote:
Any one care to comment on my blog post?
http://blog.dscpl.com.au/2010/10/is-pep--final-solution-for-wsgi-on.html
As far as web framework developers commenting, Armin at:
At 01:28 PM 10/6/2010 +0200, And Clover wrote:
On 10/05/2010 04:23 AM, P.J. Eby wrote:
A preliminary update of the standalone (Python 3.x) version of wsgiref
is now available
Is there any interest in putting fixup code into wsgiref's
CGIHandler? I appreciate this is really ugly, but the CGI
At 12:04 PM 10/4/2010 -0400, P.J. Eby wrote:
PEP has now been updated with the amendments and clarifications
that I announced two weeks ago; see this link for the (nicely
formatted) differences between PEP 333 and PEP :
http://svn.python.org/view/peps/trunk/pep-.txt?r1=85014r2
A preliminary update of the standalone (Python 3.x) version of
wsgiref is now available using easy_install wsgiref==dev. Relevant
diffs are here:
http://svn.eby-sarna.com/?rev=2689view=rev
This is preliminary work that'll need to be ported to the Python 3
version of wsgiref (note that the
At 07:15 PM 9/25/2010 -0700, Guido van Rossum wrote:
Don't see this as a new spec. See it as a procedural issue.
As a procedural issue, PEP 333 is an Informational PEP, in Draft
status, which I'd like to make Final after these amendments. See
http://www.wsgi.org/wsgi/Amendments_1.0, which
At 01:44 PM 9/26/2010 -0700, Guido van Rossum wrote:
On Sun, Sep 26, 2010 at 12:47 PM, Barry Warsaw ba...@python.org wrote:
On Sep 26, 2010, at 1:33 PM, P.J. Eby wrote:
At 08:20 AM 9/26/2010 -0700, Guido van Rossum wrote:
I'm happy approving Final status for the
*original* PEP 333 and I'm
-- maybe mark up the
differences in PEP so people can easily tell what was added. And
move PEP 333 to Final status.
--Guido
On Sun, Sep 26, 2010 at 1:50 PM, P.J. Eby p...@telecommunity.com wrote:
At 01:44 PM 9/26/2010 -0700, Guido van Rossum wrote:
On Sun, Sep 26, 2010 at 12:47 PM, Barry Warsaw
At 02:59 PM 9/26/2010 -0400, Terry Reedy wrote:
You could mark added material is a way that does not conflict with
rst or html. Or use .rst to make new text stand out in the .html web
verion (bold, underlined, red, or whatever). People familiar with
333 can focus on the marked sections. New
I have only done the Python 3-specific changes at this point; the
diff is here if anybody wants to review, nitpick or otherwise comment:
http://svn.python.org/view/peps/trunk/pep-0333.txt?r1=85014r2=85013pathrev=85014
For that matter, if anybody wants to take a crack at updating Python
3's
At 09:22 PM 9/25/2010 -0400, Jesse Noller wrote:
It seems like it will end up
different enough to be a different specification, closely related to
the original, but different enough to trip up all the people
maintaining current WSGI servers and apps.
The only actual *change* to the spec is
At 02:07 PM 9/25/2010 -0700, Guido van Rossum wrote:
This is a very laudable initiative and I approve of the changes -- but
I really think it ought to be a separate PEP rather than pretending it
is just a set of textual corrections on the existing PEP 333.
With the exception of the bytes
At 03:48 PM 9/23/2010 -0500, Ian Bicking wrote:
It only fixes the one case of non-Latin1 characters, there are still
many other values you can put into a header (a newline or control
character for instance), and innumerable header-specific
issues. It seems to be adding complexity for one of
At 09:52 AM 9/24/2010 -0600, Jeff Hardy wrote:
On Thu, Sep 23, 2010 at 10:32 AM, P.J. Eby p...@telecommunity.com wrote:
Just a reminder: I'm planning to actually update PEP 333 over the weekend
and start working on wsgiref updates, so if you have any last-minute
comments on the proposal
At 01:22 PM 9/24/2010 +0200, René Dudfield wrote:
Hi,
Have all the changes been tested with real world implementations?
mod_wsgi under Python 3 is compliant with the changes, and I believe
it has all the general addenda/clarifications implemented under
Python 2 as well (and for some years
At 12:57 PM 9/21/2010 -0400, Ian Bicking wrote:
On Tue, Sep 21, 2010 at 12:09 PM, P.J. Eby
mailto:p...@telecommunity.comp...@telecommunity.com wrote:
The Python 3 specific changes are to use:
* ``bytes`` for I/O streams in both directions
* ``str`` for environ keys and values
* ``bytes
Just a reminder: I'm planning to actually update PEP 333 over the
weekend and start working on wsgiref updates, so if you have any
last-minute comments on the proposal, now's the time to post them,
however unpolished they may be!
___
Web-SIG mailing
At 11:11 AM 9/23/2010 -0600, Jeff Hardy wrote:
On Thu, Sep 23, 2010 at 10:06 AM, P.J. Eby p...@telecommunity.com wrote:
So, unless somebody has some additional arguments on this one, I think I'm
going to stick with bytes output.
I don't have a strong opinion on whether it should be bytes
At 02:51 PM 9/23/2010 -0400, Tres Seaver wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
P.J. Eby wrote:
Just a reminder: I'm planning to actually update PEP 333 over the
weekend and start working on wsgiref updates, so if you have any
last-minute comments on the proposal, now's
At 11:17 AM 9/23/2010 -0500, Ian Bicking wrote:
I don't see any reason why Location shouldn't be ASCII. Any header
could have any character put in it, of course, there's just no valid
case where Location shouldn't be a URL, and URLs are ASCII. Cookie
can contain weirdness, yes. I would
At 08:34 AM 9/22/2010 -0700, Robert Brewer wrote:
Marcel Hellkamp wrote:
I would like to add a warning to the WSGI/web3 specification to address
this issue:
An application should read all available data from
`environ['wsgi.input']` on POST or PUT requests, even if it does not
process that
While the Web-SIG is trying to hash out PEP 444, I thought it would
be a good idea to have a backup plan that would allow the Python 3
stdlib to move forward, without needing a major new spec to settle
out implementation questions.
After all, even if PEP 333 is ultimately replaced by PEP 444,
At 12:55 PM 9/21/2010 -0400, Ian Bicking wrote:
On Tue, Sep 21, 2010 at 12:47 PM, Chris McDonough
mailto:chr...@plope.comchr...@plope.com wrote:
On Tue, 2010-09-21 at 12:09 -0400, P.J. Eby wrote:
While the Web-SIG is trying to hash out PEP 444, I thought it would
be a good idea to have
At 06:52 PM 9/21/2010 +0200, Antoine Pitrou wrote:
On Tue, 21 Sep 2010 12:09:44 -0400
P.J. Eby p...@telecommunity.com wrote:
While the Web-SIG is trying to hash out PEP 444, I thought it would
be a good idea to have a backup plan that would allow the Python 3
stdlib to move forward, without
[trimming reply headers to just web-sig]
At 12:57 PM 9/21/2010 -0400, Ian Bicking wrote:
On Tue, Sep 21, 2010 at 12:09 PM, P.J. Eby
mailto:p...@telecommunity.comp...@telecommunity.com wrote:
The Python 3 specific changes are to use:
* ``bytes`` for I/O streams in both directions
* ``str
At 09:01 AM 9/18/2010 -0700, Robert Brewer wrote:
Marcel Hellkamp wrote:
Removing any support for this type of asynchronism would render web3
useless for all but completely synchronous and trivial applications.
Even frameworks would have no way to work around this anymore.
I've run a few
At 03:43 PM 9/17/2010 +0200, And Clover wrote:
On 09/17/2010 02:03 PM, Armin Ronacher wrote:
In case we change the spec as Ian mentioned above, I am all for
a wsgi.guessed_encoding = True flag or something like that.
Yes, I'd like to see that. I believe going with *only* a
At 10:35 AM 9/16/2010 -0700, Guido van Rossum wrote:
No comments on the rest except to note that at this point it looks
unlikely that we can make everyone happy (or even get an agreement to
adopt what would be the long-term technically optimal solution --
AFAICT there is no agreement on what
At 02:17 PM 9/16/2010 -0500, Ian Bicking wrote:
On Thu, Sep 16, 2010 at 1:04 PM, P.J. Eby
mailto:p...@telecommunity.comp...@telecommunity.com wrote:
* Clarifying the encoding of environ values (locale+surrogateescape
vs. latin1, TBD)
locale+surrageescape would be insanity! CGI will just
At 07:03 PM 9/15/2010 -0400, Chris McDonough wrote:
A PEP was submitted and accepted today for a WSGI successor protocol
named Web3:
http://python.org/dev/peps/pep-0444/
I'd encourage other folks to suggest improvements to that spec or to
submit a competing spec, so we can get WSGI-on-Python3
At 02:37 PM 8/30/2010 +1000, Graham Dumpleton wrote:
Anyway, rather than keep arguing the point and move forward, let us
perhaps start now with the following definitions and new names to
identify them. We can even go a bit stupid and give each its own code
name so they are in part more
At 06:05 PM 8/27/2010 +0200, Christoph Zwerschke wrote:
For instance,
user = 'özkan'.encode('latin1')
if user in request.META.get('REMOTE_USER', b'').lower():
will not work it the user has logged in as 'Özkan'.
Isn't that a problem with code that does this now?
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
At 11:07 AM 7/16/2010 -0500, Ian Bicking wrote:
And this doesn't help with Python 3: either we have byte values of
SCRIPT_NAME and PATH_INFO in Python 3, or we have text values. I
think bytes will be more awkward to port to than text, and
inconsistent with other WSGI values.
OTOH, it has
At 02:28 PM 7/16/2010 -0500, Ian Bicking wrote:
On Fri, Jul 16, 2010 at 1:40 PM, P.J. Eby
mailto:p...@telecommunity.comp...@telecommunity.com wrote:
At 11:07 AM 7/16/2010 -0500, Ian Bicking wrote:
And this doesn't help with Python 3: either we have byte values of
SCRIPT_NAME and PATH_INFO
At 05:42 PM 7/16/2010 -0400, Tres Seaver wrote:
P.J. Eby wrote:
(Hm. Although actually, I suppose we *could* just borrow the time
machine and pretend that WSGI called for byte-strings everywhere
all along...)
I like the idea of pushing responsibility for decoding stuff into the
framework
At 10:14 AM 6/29/2010 -0600, Aaron Fransen wrote:
Couple more things I've been able to discern.
The first happened after I fixed the html code. Originally under
mod_python, I guess I was cheating more than a little bit by sending
html/html code blocks twice, once for the incremental notices,
At 12:33 PM 6/29/2010 -0600, Aaron Fransen wrote:
I was sending text/html (I probably should have used multipart
before) ... should I try multipart now, even with having everything
in a single stream?
Heck if I know. I just assumed that what you're doing would be
unlikely to work, whereas
At 01:01 PM 6/28/2010 -0600, Aaron Fransen wrote:
One of the nice things about mod_python is the req.write() function.
Although I realize it's somewhat of an abuse to the http protocol,
it's handy being able to periodically update the client browser with
a status message for a long-running
At 03:43 PM 6/28/2010 -0600, Aaron Fransen wrote:
Using mod_wsgi on Apache doesn't seem to exhibit that behavior.
You may need WSGIOutputBuffering Off in your config; see:
http://code.google.com/p/modwsgi/wiki/ConfigurationDirectives#WSGIOutputBuffering
Another possibility is that you've got
At 01:25 PM 4/12/2010 +0200, Manlio Perillo wrote:
The purpose of the extension if to just have a standard interface that
WSGI applications can use to take advantage of the possibility, offered
by asynchronous server, to suspend execution and resume it later.
WSGI has this ability now - it's
At 04:08 PM 4/8/2010 +0200, Manlio Perillo wrote:
Hi.
Some time ago I objected the decision to remove start_response function
from next version WSGI, using as rationale the fact that without
start_callable, asynchronous extension are impossible to support.
Now I have found that removing
At 04:59 PM 4/8/2010 +0200, Manlio Perillo wrote:
Aaron Watters ha scritto:
someone remind me: where is the canonical WSGI 2 spec?
http://wsgi.org/wsgi/WSGI_2.0
I assume there is a way to wrap WSGI 1 applications
without breaking them? Or is this the regex--re fiasco
all over again?
At 08:06 PM 4/8/2010 +0200, Manlio Perillo wrote:
What I'm trying to do is:
* as in the example I posted, turn Mako render function in a generator.
The reason is that I would lite to to implement support for Nginx
subrequests.
By subrequest, do you mean that one request is invoking
At 08:42 AM 1/4/2010 -0800, Aaron Watters wrote:
From: Aaron Watters arw1...@yahoo.com
If an application returns an iterable response and *also*
calls the write()... what is supposed to happen?
After carefully considering all the responses on this issue ;c)
I came up with the
At 08:42 PM 11/26/2009 -0500, James Y Knight wrote:
I move to bless mod_wsgi's definition of WSGI 1.1 [1] as the
official definition of WSGI 1.1, which describes how to implement
WSGI adapters for both Python 2.x and 3.x. It may not be perfect,
but, it's been implemented twice, and seems ot
At 12:34 PM 11/27/2009 -0500, James Y Knight wrote:
On Nov 27, 2009, at 10:20 AM, P.J. Eby wrote:
Second, I do not think that the additional
guarantees/requirements can be safely added to a 1.x version, as
they make it impossible for an app to tell whether it's *really*
running under 1.1
At 02:43 PM 9/23/2009 +1000, Graham Dumpleton wrote:
Sorry, after having had a bit of think while eating lunch, I am going
to throw up another point of view on this whole issue. So, sit back
and be just a little bit concerned.
WSGI stands for Web Server GATEWAY Interface.
My understanding is
At 08:42 AM 9/23/2009 +0200, Armin Ronacher wrote:
I then propose that we eliminate SCRIPT_NAME and PATH_INFO. Instead we
have:
IMO they should stick around for compatibility with older applications
and be latin1 encoded on Python 3. But the use is discouraged.
One or the other should be
At 11:47 AM 9/24/2009 +1000, Graham Dumpleton wrote:
After almost two years of trying to get WSGI for Python 3.0 to fly, I really
do think it is time for me to give up. I did say a while back I would
try one last push and this has been it.
I'm sorry you feel that way, and I'm sorry if I
At 04:44 PM 9/22/2009 +1000, Graham Dumpleton wrote:
2009/9/22 Mark Nottingham m...@mnot.net:
That blog entry is eleven printed pages. Given that PEP 333 also prints as
eleven pages from my browser, I suspect there's some extraneous information
in there.
Could you please summarise?
At 09:23 AM 9/22/2009 +0100, Alan Kennedy wrote:
[P.J. Eby]
Actually, latin-1 bytes encoding is the *simplest* thing that could
possibly work, since it works already in e.g. Jython, and is actually
in the spec already... and any framework that wants unicode URIs
already has to decode them
At 11:28 AM 9/22/2009 +0200, Armin Ronacher wrote:
Hi,
Alan Kennedy schrieb:
2. Give the programmer (possibly mojibake) unicode strings in the WSGI
environ anyway
3. And let them solve their problems themselves, using server
configuration or bespoke middleware
Because that problem was
At 11:30 AM 9/22/2009 +0100, Alan Kennedy wrote:
I see this as being the same as Graham's suggested approach of a
per-server configurable charset, which is then stored in the WSGI
dictionary, so that applications that have problems, i.e. that detect
mojibake in the unicode SCRIPT_NAME or
At 03:22 PM 9/22/2009 +0100, René Dudfield wrote:
On Tue, Sep 22, 2009 at 3:07 PM, P.J. Eby p...@telecommunity.com wrote:
At 11:30 AM 9/22/2009 +0100, Alan Kennedy wrote:
I see this as being the same as Graham's suggested approach of a
per-server configurable charset, which is then stored
At 05:12 PM 9/22/2009 -0700, Philip Jenvey wrote:
Because our request container is a plain, pre-fabricated dict that
doesn't permit the lazy behavior.
Not quite true; you can always write a library function,
get_foo(environ) that does the lazy caching in a private environ key,
at the cost of
At 04:30 PM 9/21/2009 +0100, René Dudfield wrote:
On Mon, Sep 21, 2009 at 4:19 PM, P.J. Eby p...@telecommunity.com wrote:
At 12:25 AM 9/21/2009 -0400, Chris McDonough wrote:
Anyway, for us slower (and maybe wrongly fearful) folks, could someone
summarize the benefits of having a WSGI
At 11:23 AM 9/21/2009 -0700, Robert Brewer wrote:
I still don't see why the environ should have multiple versions of
anything. It's not as if the HTTP request gives us multiple
Request-URI's. There's a single processing step that has to happen
somewhere: decoding the bytes of the Request-URI
At 01:15 PM 9/21/2009 -0700, Robert Brewer wrote:
I don't understand. If SCRIPT_NAME/PATH_INFO/QUERY_STRING are
unicode, the only answer to what's been done to the URI? can be
wsgi.uri_encoding, which allows someone to un-do it. What more do you want?
To be sure that there's no possible way
At 03:26 PM 9/21/2009 -0700, Robert Brewer wrote:
It looks simpler until you have a site that is not primarily utf-8. In
that case, you multiply your (1 line * number of middlewares in the WSGI
stack * each request). With wsgi.uri_encoding you get either (1 line * 1
middleware designed to
At 07:40 PM 9/21/2009 -0700, Robert Brewer wrote:
Yes; you have to transcode to the correct encoding. Once. Then every
other WSGI application interface below that one doesn't have to care.
You can only do that if you *break encapsulation*, which as I said
earlier is voiding the entire point
At 07:21 PM 9/21/2009 -0700, Robert Brewer wrote:
I've never proposed that WSGI make choices for people. I'm simply
saying that a configurable server, with a sane, perfectly-reversible
default, is the simplest thing that could possibly work.
Actually, latin-1 bytes encoding is the *simplest*
At 02:30 PM 9/22/2009 +1000, Graham Dumpleton wrote:
Someone did say something about being able to half make it work on
Python 2.X. Can someone properly provide example code for Python 2.X.
The issue is that error handlers on encode are only allowed to
provide substitute unicode characters,
At 03:06 PM 9/20/2009 +0200, Armin Ronacher wrote:
Hello everybody,
Thanks to Graham Dumpleton and Robert Brewer there is some serious
progress on WSGI currently. I proposed a roadmap with some PEP changes
now that need some input.
Summary:
WSGI 1.0 stays the same as PEP 0333
At 08:48 AM 9/20/2009 -0400, Etienne Robillard wrote:
Good plan but I'm afraid now only a bunch of elite people on this list
is going to remember all the details on theses upcoming
specifications. Why the rush to specify WSGI 3.0 and not focus
mainly on the next one ahead ?
Because having more
At 04:50 PM 9/20/2009 +0200, Armin Ronacher wrote:
Django, Pylons, SQLAlchemy, Mako, Jinja2, Genshi, Werkzeug, WebOb and
many more technologies are based on unicode, even in Python 2.x. They
are currently doing decoding of byte data internally.
In Python 2.x if we stick to native strings for
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*
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
1 - 100 of 116 matches
Mail list logo