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, t
At 02:02 PM 4/15/2011 -0400, Jim Fulton wrote:
On Fri, Apr 15, 2011 at 1:32 PM, Éric Araujo 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, command hooks
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
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 are brough
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 li
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 l
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 08:09 PM 1/9/2011 +0200, Alex Grönholm wrote:
Asynchronous applications may not be ready to send the status line
as the first thing coming out of the generator.
So? In the sketches that are the subject of this thread, it doesn't
have to be the first thing. If the application yields a futu
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
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 f
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 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
As a semi-proof-of-concept, I whipped these up:
http://peak.telecommunity.com/DevCenter/AsyncWSGISketch
It's an expanded version of my Coroutine concept, updated with sample
server code for both a synchronous server and an asynchronous
one. The synchronous "server" is really just a decorato
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 pro
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 exception
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 and
At 03:26 AM 1/8/2011 -0800, Alice BevanMcGregor wrote:
Warning: this assumes we're running on bizzaro-world PEP 444 that
mandates applications are generators. Please do not dismiss this
idea out of hand but give it a good look and maybe some feedback. ;)
First-glance feedback: I'm impressed
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
by>>>incorporating>the most co
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 11:47 AM 1/7/2011 -0600, Timothy Farrell wrote:
There has been much discussion about how to handle async in PEP 444
and that discussion centers around the use of futures. However, I'm
requesting that servers _optionally_ provide
environ['wsgi.executor'] as a futures executor that applicatio
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
incorporating>the most common (1%) of features most often
relegated to middleware>or functional helpers.
Note that nearly every appli
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 sacle
At 05:27 PM 1/7/2011 +1100, Graham Dumpleton wrote:
Another thing though. For output changed to sys.stdout.buffer. For
input should we be using sys.stdin.buffer as well if want bytes?
%&$*()&%!!! Sorry, still getting used to this whole Python 3
thing. (Honestly, I don't even use Python 2.6 f
At 05:13 PM 1/7/2011 +1100, Graham Dumpleton wrote:
The version at:
http://svn.python.org/projects/peps/trunk/pep-.txt
still shows:
elif not headers_sent:
# Before the first output, send the stored headers
status, response_headers = headers_sent[:] = heade
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 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 serve
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 to
At 10:33 AM 1/4/2011 -0800, Guido van Rossum wrote:
But the flush() I was referring to is actually *before* either of
these, suggesting
sys.stdout.flush()
sys.stdout.buffer.write(data)
sys.stdout.buffer.flush()
However the first flush() is only necessary is there's a possibility
that previously
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 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 hav
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 P
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 12:43 PM 1/4/2011 +, Antoine Pitrou wrote:
Alice BevanMcGregor 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
progr
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 bin
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 04:43 PM 1/3/2011 -0800, Guido van Rossum wrote:
On Mon, Jan 3, 2011 at 3:13 PM, Jacob Kaplan-Moss wrote:
> On Sun, Jan 2, 2011 at 9:21 AM, Guido van Rossum wrote:
>> Although [PEP ] is still marked as draft, I personally think of it
>> as accepted; [...]
>
> What does it take to get PEP
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 sho
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 b
At 01:47 AM 1/2/2011 -0800, Alice BevanMcGregor wrote:
The only things that depress me in the slightest are the lack of
current discussion on the Web-SIG list (I did post a thread
announcing my rewrite and asking for input, but there were no takers)
FWIW, my lack of interest has been due to t
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 cont
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 envir
At 02:26 PM 10/23/2010 +0300, Armin Ronacher wrote:
Hi,
On 10/22/10 2:35 AM, Graham Dumpleton wrote:
has said:
"""Hopefully not. WSGI could do better and there is a proposal for
that (444)."""
Just to give this some more context: I think WSGI (even in Python 2)
is faulty and we have the po
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:
http://www.reddit.com/r/Python/comments/du7bf/is_pep__the_f
At 09:37 PM 10/9/2010 +0200, And Clover wrote:
On 10/06/2010 07:21 PM, P.J. Eby wrote:
How would these relate to the Python 3.2 release? Can you make 3.x and
2.x versions?
Yes, I have separate fixup code paths for 2.x and 3.x. 3.x faces the
reverse situation to that previously described, in
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,
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=2689&view=rev
This is preliminary work that'll need to be ported to the Python 3
version of wsgiref (note that
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=85014&am
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=85014&r2=HEAD
Or this link for the full PEP:
http:/
At 01:22 PM 9/27/2010 -0400, Terry Reedy wrote:
On 9/26/2010 9:38 PM, P.J. Eby wrote:
At 11:15 AM 9/27/2010 +1000, Ben Finney wrote:
You misunderstand me; I wasn't asking how to *add* a link, but how to
turn OFF the automatic conversion of the phrase "PEP 333" that happ
At 11:15 AM 9/27/2010 +1000, Ben Finney wrote:
"P.J. Eby" <<http://mail.python.org/mailman/listinfo/python-dev>pje
at telecommunity.com> writes:
> (For that matter, if anybody knows how to make it not turn *every* PEP
> reference into a link, that'd be go
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 rea
-- 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 wrote:
> At 01:44 PM 9/26/2010 -0700, Guido van Rossum wrote:
>>
>> On Sun, Sep 26, 2010 at 12:47 PM, Barry Wa
At 01:44 PM 9/26/2010 -0700, Guido van Rossum wrote:
On Sun, Sep 26, 2010 at 12:47 PM, Barry Warsaw 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
>>&g
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 happy to approve a new PEP which includes
PJE's corrections.
Can we make it PEP , then? ;-)
That number would at least communicate that it's the same thing, but
for Py
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 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 change
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 mand
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=85014&r2=85013&pathrev=85014
For that matter, if anybody wants to take a crack at updating Python
3'
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 no
At 09:52 AM 9/24/2010 -0600, Jeff Hardy wrote:
On Thu, Sep 23, 2010 at 10:32 AM, 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'
At 01:45 PM 9/24/2010 +0200, Manlio Perillo wrote:
Il 23/09/2010 18:32, P.J. Eby ha scritto:
> 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 th
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 t
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 ex
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 propo
At 11:11 AM 9/23/2010 -0600, Jeff Hardy wrote:
On Thu, Sep 23, 2010 at 10:06 AM, P.J. Eby 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 or strin
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 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.com>p...@telecommunity.com> wrote:
The Python 3 specific changes are to use:
* ``bytes`` for I/O streams in both directions
* ``str`` for environ keys and valu
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
[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.com>p...@telecommunity.com> wrote:
The Python 3 specific changes are to use:
* ``bytes`` for I/O streams in both direct
At 06:52 PM 9/21/2010 +0200, Antoine Pitrou wrote:
On Tue, 21 Sep 2010 12:09:44 -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 a backup plan that would allow the Python 3
> stdlib to move forward, with
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.com>chr...@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
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 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
raw-or-reconstru
At 02:54 PM 9/16/2010 -0400, Chris McDonough wrote:
On Thu, 2010-09-16 at 14:04 -0400, P.J. Eby wrote:
> 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
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.com>p...@telecommunity.com> wrote:
* Clarifying the encoding of environ values (locale+surrogateescape
vs. latin1, TBD)
locale+surrageescape would be insanity
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 that
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 s
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 memorable.
At 11:16 AM 8/30/2010 +1000, Graham Dumpleton wrote:
Although I almost begged that if we are going to discuss bytes,
compared to text/unicode, that agreement at least first be made about
the definition of the bytes leaning option, that request has pretty
well fallen on death ears.
Did you not s
At 02:17 PM 8/27/2010 +1000, Graham Dumpleton wrote:
Since the major stumbling block, irrespective of other changes, to any
sort of agreement is still bytes vs unicode, and where we have a
reasonable clear definition of what unicode suggestion is, can we
please as a first step get a definition of
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:37 AM 8/27/2010 +0200, Armin Ronacher wrote:
Hi,
Is there a status update on that now I missed? Did something decide
on bytes for the environment values or are we still unsure about that?
To the extent we're "unsure", I think the holdup is simply that
nobody has tried doing an all-byt
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 07:20 PM 7/16/2010 -0400, Chris McDonough wrote:
I'd much rather say be able to say:
"""
The PATH_INFO environment variable is a ``bytes-with-benefits`` type.
To decode it:
- First, split it on slashes::
segments = PATH_INFO.split('/')
- Then, de-encode each segment's urlencoded portio
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 deco
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.com>p...@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_N
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 th
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 mu
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
code blocks twice, once for the incremental notices,
once fo
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 go
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 job
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 yi
At 02:04 PM 4/10/2010 +0100, Chris Dent wrote:
I realize I'm able to build up a complete string or yield via a
generator, or a whole bunch of various ways to accomplish things
(which is part of why I like WSGI: that content is just an iterator,
that's a good thing) so I'm not looking for a statem
At 10:18 PM 4/8/2010 +0200, Manlio Perillo wrote:
Suppose I have an HTML template file, and I want to use a sub request.
...
${subrequest('/header/'}
...
The problem with this code is that, since Mako will buffer all generated
content, the result response body will contain incorrect data.
It w
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 anothe
At 05:40 PM 4/8/2010 +0200, Manlio Perillo wrote:
With WSGI 2.0 we will end up with:
- WSGI 1.0, a full featured protocol, but with hard to implement
middlewares
- WSGI 2.0, a simple protocol, with more easy to implement middlewares
but without support for some "advanced" applications
Let
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 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 start_r
At 08:10 PM 3/27/2010 +0100, Manlio Perillo wrote:
Some time ago, someone reported me that an application embedded in Nginx
with my WSGI module failed to execute, since in my implementation the
wsgi.errors object does not implement the .close method.
We should probably note in the spec that WSG
1 - 100 of 152 matches
Mail list logo
