[Web-SIG] WSGI is now Python 3-friendly
P.J. Eby
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's wsgiref based on the above, feel free. ;-) I'll be happy to
answer any questions I can that come up in the process.
(Please note: I went with Ian Bicking's "headers are strings, bodies
are bytes" proposal, rather than my original "bodies and outputs are
bytes" one, as there were not only some good arguments in its favor,
but because it also resulted in fewer changes to the PEP, especially
in the code samples.)
I will continue to work on adding the other addenda/errata mentioned here:
http://mail.python.org/pipermail/web-sig/2010-September/004655.html
But because these are "shoulds" rather than musts, and apply to both
Python 2 and 3, they are not as high priority for immediate
implementation in wsgiref and do not necessarily need to hold up the
3.2 release.
(Nonetheless, if anybody is willing to implement them in the Python 3
version, I will happily review the changes for backport into the
Python 2 standalone version of wsgiref, and issue an updated release
to include them.)
Thanks!
_______________________________________________
Web-SIG mailing list
Web...@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/python-web-sig-garchive-9074%40googlegroups.com
Guido van Rossum
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.
--Guido
On Sat, Sep 25, 2010 at 12:56 PM, P.J. Eby <p...@telecommunity.com> wrote:
> 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's
> wsgiref based on the above, feel free. ;-) I'll be happy to answer any
> questions I can that come up in the process.
>
> (Please note: I went with Ian Bicking's "headers are strings, bodies are
> bytes" proposal, rather than my original "bodies and outputs are bytes" one,
> as there were not only some good arguments in its favor, but because it also
> resulted in fewer changes to the PEP, especially in the code samples.)
>
> I will continue to work on adding the other addenda/errata mentioned here:
>
> http://mail.python.org/pipermail/web-sig/2010-September/004655.html
>
> But because these are "shoulds" rather than musts, and apply to both Python
> 2 and 3, they are not as high priority for immediate implementation in
> wsgiref and do not necessarily need to hold up the 3.2 release.
>
> (Nonetheless, if anybody is willing to implement them in the Python 3
> version, I will happily review the changes for backport into the Python 2
> standalone version of wsgiref, and issue an updated release to include
> them.)
>
> Thanks!
>
> _______________________________________________
> Python-Dev mailing list
> Pytho...@python.org
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/guido%40python.org
>
--
--Guido van Rossum (python.org/~guido)
P.J. Eby
>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 mandating the use of the
'bytes' type or equivalent for HTTP bodies when using Python 3.
Seriously, that's *it*.
Everything else that's (planned to be) added is either 100% truly
just clarifications (e.g. nothing in the spec *ever* said SERVER_PORT
could be an int, but apparently some people somehow interpreted it
so), or else best-practice recommendations from people who actually
implemented WSGI servers.
For example, the readline() size hint is "not supported" in the
original spec (meaning clients can't call it and be compliant). The
planned modification is "servers should implement it" (best
practice), but you can't call an implementation that *doesn't*
implement it noncompliant. (This just addresses the fact that most
practical implementations *did* in fact support it, and code out
there relies on this.)
So, no (previously-)compliant implementations were harmed in the
making of the updated spec. If they were compliant before, they're
compliant now.
I'm actually a bit surprised people are bringing this up now, since
when I announced the plan to make these changes, I said that nothing
would be changed that would break anything... even for what I
believe are the only Python 3 WSGI implementations right now (by
Graham Dumpleton and Robert Brewer).
Indeed, all of the changes (except the bytes thing) are stuff
previously discussed endlessly on the Web-SIG (years ago in most
cases) and widely agreed on as, "this should have been made clear in
the original PEP".
And, I also explicitly deferred and/or rejected items that *can't* be
done in a 100% backward-compatible way, and would have to be WSGI 1.1
or higher -- indeed, I have a long list of changes from Graham that
I've pronounced "can't be done without a 1.1".
Indeed, the entire point of the my scope choices were to allow all
this to happen *without* a whole new spec. ;-)
P.J. Eby
>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, I ruled out accepting any
proposed amendments that would actually alter the protocol. The
amendments are all either textual clarifications, clarifications of
ambiguous/unspecified areas, or best-practice recommendations by
implementors. (i.e., which are generally already implemented in major servers)
The full list of things Graham and others have asked for or
recommended would indeed require a 1.1 version at minimum, and thus a
new PEP. But I really don't want to start down that road right now,
and therefore hope that I can talk Graham or some other poor soul
into shepherding a 1.1 PEP instead. ;-)
(Seriously: through an ironic twist of fate, I have done nearly
*zero* Python web programming since around the time I drafted the
first spec in 2004, so even if it makes sense for me to finish PEP
333, it makes little sense for me to be starting a *new* one on the topic now!)
Guido van Rossum
> 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, I ruled out accepting any proposed
> amendments that would actually alter the protocol. The amendments are all
> either textual clarifications, clarifications of ambiguous/unspecified
> areas, or best-practice recommendations by implementors. (i.e., which are
> generally already implemented in major servers)
Of those, IMO only textual clarifications ought to be made to an
existing, accepted, widely implemented standards-track PEP.
Clarifications of ambiguous/unspecified behavior can possibly rule as
non-conforming implementations that used to get the benefit of the
doubt. Best-practice recommendations also have the effect of changing
(perceived) compliance.
Really, what's the problem with creating a new PEP? PEPs are cheap --
it's getting the acceptance that's costly, and you've already gotten
that part. It doesn't have to be long. You can still make pure textual
clarifications to PEP 333 (basically, improve grammar) and add a
pointer to the new PEP. Or, you can create a new PEP that is an
updated copy of PEP 333, and just add a pointer to PEP 333 saying
"(especially in the context of Python 3) this PEP is now superseded by
PEP XXXX".
I strongly disagree with using (standards-track) PEPs as mutable
documents -- before you know it people will have to use weasel words
like "compliant with PEP 333 as of date X" to describe their
software's conformity. If you add a new PEP #, software declared
compliant with PEP 333 remains compliant (and some such software can
now also claim compliance with the new PEP without any changes).
> The full list of things Graham and others have asked for or recommended
> would indeed require a 1.1 version at minimum, and thus a new PEP. But I
> really don't want to start down that road right now, and therefore hope that
> I can talk Graham or some other poor soul into shepherding a 1.1 PEP
> instead. ;-)
That's fine. It will just be another PEP.
> (Seriously: through an ironic twist of fate, I have done nearly *zero*
> Python web programming since around the time I drafted the first spec in
> 2004, so even if it makes sense for me to finish PEP 333, it makes little
> sense for me to be starting a *new* one on the topic now!)
Don't see this as a new spec. See it as a procedural issue.
--
--Guido van Rossum (python.org/~guido)
P.J. Eby
>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 Graham created in 2007, stating:
"""This page is intended to collect any ideas related to amendments
to the original WSGI 1.0 so that it can be marked as 'Final'."""
IOW, there is no intention to treat the PEP as "mutable" going
forward; this is just cleanup so we can mark it Final. After that,
it's an ex-parrot.
>Clarifications of ambiguous/unspecified behavior can possibly rule as
>non-conforming implementations that used to get the benefit of the
>doubt. Best-practice recommendations also have the effect of changing
>(perceived) compliance.
I understand the general principle, but with respect to these
*specific* changes, any perceived-compliance arguments that were
going to happen, already happened years ago. The changes are merely
to officially document the way those arguments already turned out, so
the PEP can become Final.
Specifically, the changes all fall into one of three categories:
1. Textual clarification (SERVER_PORT is not an int, iteration can
stop before all output is consumed)
2. Practical issues with wsgi.input arising from the fact that
real-world programs needed its behavior to be more "file-like" than
the specification required... and which essentially forced servers
that were not using socket.makefile() to make their emulations work
like that, anyway (or else be rejected by users).
3. Clarification of behavior that would break HTTP compliance (apps
or servers sending more than Content-Length bytes) and is therefore
*already a bug* in any implementation that does it.
Since in all three categories any implementation that did not end up
following the recommendations on its own is going to have been
considered buggy by its users (regardless of its formal
"compliance"), and because the changes do not actually declare the
buggy behaviors in categories 2 and 3 to be non-compliant, I do not
see how any of these changes can produce the type of problems you're
worried about here.
Certainly, if I thought such problems were possible, I wouldn't have
accepted these amendments. Likewise, if I thought that changes would
continue to be made to the PEP past this point, the goal wouldn't be
getting it to Final status.
Guido van Rossum
> I hadn't realized that PEP 333 was never actually in the 'Final' status
> (de facto, it has been so for years, of course). Given that fact, and
> PJEs assurances, I think amending the PEP and then immediately declaring
> it final is reasonable.
And who is going to give the PEP its stamp of approval?
I'm sorry, but all this weasel-wording about how these changes aren't
really changes and how this standard wasn't really a standard make me
very uncomfortable. 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. I'm not going to approve Final status for a
history-rewrite of PEP 333.
--
--Guido van Rossum (python.org/~guido)
P.J. Eby
>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 3333, then? ;-)
That number would at least communicate that it's the same thing, but
for Python 3.
Really, my reason for trying to do the (non Py3-specific) amendments
in a way that didn't require a new PEP number was because of the many
ancillary questions that it raises for the community, such as:
* Is this is some sort of competition/replacement to PEP 444?
* What happened to the old one, why can't we just use that?
* Why isn't there a different protocol version?
* How is this different from the old one?
To be fair, I *also* wanted to avoid all the work associated with
*answering* them. ;-) (Heck, I really wanted to avoid the work of
having to even *think* about which questions *might* arise and how
they'd need to be addressed.)
OTOH, I can certainly see that my attempt to avoid this has *already*
failed: it simply brought up a different set of questions, just on
Python-Dev instead of Web-SIG or Python-list.
Oh well. Perhaps making the numbering appear to be a continuation
will help a bit.
Another option would be to make a PEP that consists solely of the
amendments and errata themselves, as this would answer most of the
above questions directly.
Still another would be to abandon the effort to amend the PEP, and
simply leave things as they are now: AFAICT, the fact that these
amendments aren't in the PEP hasn't stopped anybody from *treating*
most of them as if they were. (Because everyone understands that
failure to follow them constitutes a bug in your program, even if it
technically complies with the spec.)
Terry Reedy
Thank you do doing the needed rewrite.
> Can we make it PEP 3333, then? ;-)
>
> That number would at least communicate that it's the same thing, but for
> Python 3.
A new rewriten PEP gives you a bit more freedom than doing it in place.
It will be easier to refer to the existing PEP 333 rather than "an
earlier version of this PEP".
>
> Really, my reason for trying to do the (non Py3-specific) amendments in
> a way that didn't require a new PEP number was because of the many
> ancillary questions that it raises for the community, such as:
>
> * Is this is some sort of competition/replacement to PEP 444?
> * What happened to the old one, why can't we just use that?
> * Why isn't there a different protocol version?
You can also (briefly) answer questions like these in a new section.
I would refer people to the web-sig if they have further questions.
> * How is this different from the old one?
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 readers can ignore the marking.
> To be fair, I *also* wanted to avoid all the work associated with
> *answering* them. ;-) (Heck, I really wanted to avoid the work of having
> to even *think* about which questions *might* arise and how they'd need
> to be addressed.)
>
> OTOH, I can certainly see that my attempt to avoid this has *already*
> failed: it simply brought up a different set of questions, just on
> Python-Dev instead of Web-SIG or Python-list.
You can't win in situations like this.
> Oh well. Perhaps making the numbering appear to be a continuation will
> help a bit.
>
> Another option would be to make a PEP that consists solely of the
> amendments and errata themselves, as this would answer most of the above
> questions directly.
Please no. Terrible to read. Mark important changes, as suggested above,
in a complete text.
>
> Still another would be to abandon the effort to amend the PEP, and
> simply leave things as they are now: AFAICT, the fact that these
> amendments aren't in the PEP hasn't stopped anybody from *treating* most
> of them as if they were. (Because everyone understands that failure to
> follow them constitutes a bug in your program, even if it technically
> complies with the spec.)
Please no ;-).
--
Terry Jan Reedy
Guido van Rossum
> 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 happy to approve a new PEP which includes
>>> PJE's corrections.
>>
>> Can we make it PEP 3333, then? ;-)
>
Go for it.
--
--Guido van Rossum (python.org/~guido)
P.J. Eby
>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 happy to approve a new PEP which includes
> >>> PJE's corrections.
> >>
> >> Can we make it PEP 3333, then? ;-)
> >
> > That works for me.
>
>Go for it.
Shall I just "svn cp" it, then (to preserve edit history), or wait
for the PEP editor do it?
Guido van Rossum
mostly exists to assure non-committers are not prevented from
authoring PEPs.
Please do add a prominent note at the top of PEP 333 pointing to PEP
3333 for further information on Python 3 compliance or some such
words. Add a similar note at the top of PEP 3333 -- maybe mark up the
differences in PEP 3333 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 <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 happy to approve a new PEP which includes
>> >>> PJE's corrections.
>> >>
>> >> Can we make it PEP 3333, then? ;-)
>> >
>> > That works for me.
>>
>> Go for it.
>
> Shall I just "svn cp" it, then (to preserve edit history), or wait for the
> PEP editor do it?
>
>
--
--Guido van Rossum (python.org/~guido)
P.J. Eby
reverted the Python 3 bit after moving it to the new PEP. I'll make
the changes to 3333 instead as soon as I have another time slot free.
>Python-Dev mailing list
>Pytho...@python.org
>http://mail.python.org/mailman/listinfo/python-dev
>Unsubscribe:
>http://mail.python.org/mailman/options/python-dev/pje%40telecommunity.com
P.J. Eby
>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 readers can ignore the marking.
If you (or anybody else) have any idea how to do that (highlight
stuff in PEP-dialect .rst), let me know.
(For that matter, if anybody knows how to make it not turn *every*
PEP reference into a link, that'd be good too! It doesn't really
need to turn 5 or 6 occurrences of "PEP 333" in the same paragraph
into separate links. ;-) )
Ben Finney
> (For that matter, if anybody knows how to make it not turn *every* PEP
> reference into a link, that'd be good too! It doesn't really need to
> turn 5 or 6 occurrences of "PEP 333" in the same paragraph into
> separate links. ;-) )
reST, being designed explicitly for Python documentation, has support
for PEP references built in:
The :pep-reference: role is used to create an HTTP reference to a
PEP (Python Enhancement Proposal). The :PEP: alias is usually used.
For example:
See :PEP:`287` for more information about reStructuredText.
This is equivalent to:
See `PEP 287`__ for more information about reStructuredText.
__ http://www.python.org/peps/pep-0287.html
<URL:http://docutils.sourceforge.net/docs/ref/rst/roles.html#pep-reference>.
--
\ “What is needed is not the will to believe but the will to find |
`\ out, which is the exact opposite.” —Bertrand Russell |
_o__) |
Ben Finney
P.J. Eby
>"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 good too! It doesn't really need to
> > turn 5 or 6 occurrences of "PEP 333" in the same paragraph into
> > separate links. ;-) )
>
>reST, being designed explicitly for Python documentation, has support
>for PEP references built in:
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
happens without any special markup.
Currently, the PEP 3333 preface is littered with unnecessary links,
because the PEP pre-processor turns *every* mere textual mention of a
PEP into a link to it.
P.J. Eby
>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 happens
>>without any special markup.
>
>>Currently, the PEP 3333 preface is littered with unnecessary links,
>>because the PEP pre-processor turns *every* mere textual mention of a
>>PEP into a link to it.
>
>popping up a windowed asking me what file I want to at.tach
>everytime I write the word "at-tach' or a derivative without the
>extra punctuation. It would definitely not be the vehicle for
>writing about at=mentment syndromes.
>
>Suggestion pending something better from rst/PEP experts:
>"This PEP extends PEP 333 (abbreviated P333 hereafter)."
>perhaps with "to avoid auto-link creation" added before ')' to
>pre-answer pesky questions and to avoid some editor re-expanding the
>abbreviations.
It turns out that using a backslash before the number (e.g. PEP \333)
turns off the automatic conversion.
The PEP still hasn't showed up on Python.org, though, so I'm
wondering if maybe I broke something else somewhere.