You're twisting my words; nowhere did I say i wasn't willing to read
the PEP. What I did say was that a proposal can and should be made in
less than eleven pages; I'd like to give my feedback, both because I
use Python and because I have some interest in HTTP. However, my time
is limited, and I already have a stack of other things to review on my
desk.
He who writes the most words does not (hopefully, for the sake of the
Python community) win. I appreciate that you've taken the time to
reason out a proposal, but the minutia of how you got to that place
should not obscure the proposal itself.
I'm not sure how to take your "ticket monkeys" comment, so I'll ignore
it.
On 22/09/2009, at 4:44 PM, 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? Requiring all comers to read such a
voluminous
entry is a considerable (and somewhat arbitrary) bar to entry for the
discussion.
If you aren't willing to read the PEP to understand WSGI why are you
even wanting to participate in the discussion in the first place? This
is a quite detailed discussion about the future of the WSGI
specification and not an IRC channel manned by ticket monkeys. :-(
Graham
Thanks,
On 22/09/2009, at 4:36 PM, Graham Dumpleton wrote:
2009/9/22 Mark Nottingham <m...@mnot.net>:
So, what advice do you propose about decoding bytes into strings
for the
request-URI / method / request headers, and vice versa for response
headers
and status code/phrase? Do you assume ASCII, Latin-1, or UTF-8?
How are
errors handled?
Are bodies still treated "as binary byte sequences", as per PEP
333?
I thought my blog post explained that reasonably well. Ensure you
read
the numbered definitions.
If you can't work it out from the blog, point at the specific
thing in
the blog you don't understand and can help. Don't really want to go
explaining it all again.
Graham
Cheers,
On 22/09/2009, at 4:07 PM, Graham Dumpleton wrote:
2009/9/22 Mark Nottingham <m...@mnot.net>:
OK, that's quite exhaustive.
For the benefit of those of us jumping in, could you summarise
your
proposal
in something like the following manner:
1. How the request method is made available to WSGI applications
2. How the request-uri is made available to WSGI applications
-- in
particular, whether any decoding of punycode and/or %-escapes
happens
3. How request headers are made available to WSGI apps
4. How the request body is made available to to WSGI apps
5. Likewise for how apps should expose the response status
message,
headers
and body to WSGI implementations.
Same as the WSGI PEP.
http://www.python.org/dev/peps/pep-0333/
Nothing has changed in that respect.
Graham
Cheers,
On 22/09/2009, at 12:26 PM, Graham Dumpleton wrote:
2009/9/22 Mark Nottingham <m...@mnot.net>:
Reference?
See:
http://blog.dscpl.com.au/2009/09/roadmap-for-python-wsgi-specification.html
Anyone else jumping in on this conversation with their own
opinions
and who has not read it, should perhaps at least read that.
Also read
some of the earlier posts in the numerous discussions this
spawned at:
http://groups.google.com/group/python-web-sig?lnk=
as the current thinking isn't exactly what I blogged about and
has
shifted a bit as the discussion has progressed.
Graham
On 22/09/2009, at 12:07 PM, Graham Dumpleton wrote:
2009/9/22 Mark Nottingham <m...@mnot.net>:
Most things is not the Web. How will you handle serving
images
through
WSGI?
Compressed content? PDFs?
You are perhaps misunderstanding something. A WSGI
application still
should return bytes.
The whole concept of any sort of fallback to allow unicode
data to
be
returned for response content was purely so the canonical
hello
world
application as per Python 2.X could still be used on Python
3.X.
So, we aren't saying that the only thing WSGI applications can
return
is unicode strings for response content.
Have you read my original blog post that triggered all this
discussion
this time around?
Graham
On 22/09/2009, at 1:30 AM, René Dudfield wrote:
here is a summary:
Apart from python3 compatibility(which should be good
enough
reason), utf-8 is what's used in http a lot these days.
Most
things
layered on top of wsgi are using utf-8 (django etc), and
lots of
web
clients are using utf-8 (firefox etc).
Why not move to unicode?
--
Mark Nottingham http://www.mnot.net/
_______________________________________________
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/graham.dumpleton%40gmail.com
--
Mark Nottingham http://www.mnot.net/
--
Mark Nottingham http://www.mnot.net/
--
Mark Nottingham http://www.mnot.net/
--
Mark Nottingham http://www.mnot.net/
--
Mark Nottingham http://www.mnot.net/
_______________________________________________
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
