Re: [Python-Dev] WSGI is now Python 3-friendly
Am 26.09.2010 03:45, schrieb P.J. Eby: 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 I think people read this as nothing would be changed, period. However, you did make substantial changes to the specification (or else the whole exercise would have been pointless, I suppose, and you couldn't have claimed that WSGI is now Python 3-friendly when it previously was not). So this is essentially a new version of the spec. As PEPs themselves are not versioned (unlike, say, ISO standards), Guido insists it ought to get a new PEP number. Then, people declaring compliance can identify what specification they actually comply to. Declaring compliance to PEP 333 as-of-last-week-but-not-as-of-today is now difficult. This particularly puzzles people some of the existing WSGI servers are now incompatible to the PEP, when they still were compatible last week. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] WSGI is now Python 3-friendly
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 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. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] WSGI is now Python 3-friendly
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 09/26/2010 02:31 AM, Martin v. Löwis wrote: Am 26.09.2010 03:45, schrieb P.J. Eby: 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 I think people read this as nothing would be changed, period. However, you did make substantial changes to the specification (or else the whole exercise would have been pointless, I suppose, and you couldn't have claimed that WSGI is now Python 3-friendly when it previously was not). The clarifications remove Python3-only ambiguities, making it possible for to implement both sides the spec sanely and consistently under Python 3. So this is essentially a new version of the spec. As PEPs themselves are not versioned (unlike, say, ISO standards), Guido insists it ought to get a new PEP number. Then, people declaring compliance can identify what specification they actually comply to. Declaring compliance to PEP 333 as-of-last-week-but-not-as-of-today is now difficult. This particularly puzzles people some of the existing WSGI servers are now incompatible to the PEP, when they still were compatible last week. PJE's claim is that there are *no* such servers: So, no (previously-)compliant implementations were harmed in the making of the updated spec. If they were compliant before, they're compliant now. 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. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkyfX6MACgkQ+gerLs4ltQ7tjgCfXP4SamlyjLenSsHib0O8E03d MbEAnR+lsNoUb7PH4NkdKNL1rToWXTsi =s5d7 -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] WSGI is now Python 3-friendly
On Sun, Sep 26, 2010 at 7:58 AM, Tres Seaver tsea...@palladion.com wrote: 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) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] WSGI is now Python 3-friendly
I think people read this as nothing would be changed, period. However, you did make substantial changes to the specification (or else the whole exercise would have been pointless, I suppose, and you couldn't have claimed that WSGI is now Python 3-friendly when it previously was not). The clarifications remove Python3-only ambiguities, making it possible for to implement both sides the spec sanely and consistently under Python 3. Sure. I don't argue whether this is an improvement. I claim that it is a specification change, long after the specification has been implemented multiple times. It thus deserves to get a new name (i.e. PEP number). PJE says that strictly speaking, the PEP had not been accepted yet. However, at this stage, claiming that it is still open for edits is really confusing, IMO. So this is essentially a new version of the spec. As PEPs themselves are not versioned (unlike, say, ISO standards), Guido insists it ought to get a new PEP number. Then, people declaring compliance can identify what specification they actually comply to. Declaring compliance to PEP 333 as-of-last-week-but-not-as-of-today is now difficult. This particularly puzzles people some of the existing WSGI servers are now incompatible to the PEP, when they still were compatible last week. PJE's claim is that there are *no* such servers: Does that claim include wsgiref? 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. I'm still with Guido here: I'd accept PEP 333 as final in the state it had last week, give PJE's edits a new PEP number, and accept that as final right away also. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] WSGI is now Python 3-friendly
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. +1 Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] WSGI is now Python 3-friendly
Martin v. Löwis martin at v.loewis.de writes: I'm still with Guido here: I'd accept PEP 333 as final in the state it had last week, give PJE's edits a new PEP number, and accept that as final right away also. This sounds like it should make everyone happy - no rewriting of history, and no procedural roadblocks or delays to the amendments PJE wants to make. Are we done here, or am I missing something? ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] WSGI is now Python 3-friendly
On 26 September 2010 19:01, Vinay Sajip vinay_sa...@yahoo.co.uk wrote: Martin v. Löwis martin at v.loewis.de writes: I'm still with Guido here: I'd accept PEP 333 as final in the state it had last week, give PJE's edits a new PEP number, and accept that as final right away also. This sounds like it should make everyone happy - no rewriting of history, and no procedural roadblocks or delays to the amendments PJE wants to make. Are we done here, or am I missing something? Sounds fine to me (PJE's response to Guido seems to imply he might still have an issue, but I really hope not - let's get the new version finalised and move on). Paul. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] WSGI is now Python 3-friendly
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 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 Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] WSGI is now Python 3-friendly
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. --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=85014r2=85013pathrev=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 Python-Dev@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) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] WSGI is now Python 3-friendly
On Sat, Sep 25, 2010 at 3: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=85014r2=85013pathrev=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! This looks like good progress (and does not seem to block the progress of PEP 444) but would it be possible to do it as a different PEP rather then just an update; or adding an explicit these are the differences between v1 and v2 section? 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. jesse ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] WSGI is now Python 3-friendly
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 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. ;-) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] WSGI is now Python 3-friendly
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) 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!) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] WSGI is now Python 3-friendly
On Sat, Sep 25, 2010 at 7:00 PM, P.J. Eby p...@telecommunity.com wrote: 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 . 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) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
