Re: [Python-Dev] [Web-SIG] WSGI is now Python 3-friendly
On Tue, Sep 28, 2010 at 8:17 AM, Guido van Rossum gu...@python.org wrote: On Mon, Sep 27, 2010 at 2:21 PM, Martin v. Löwis mar...@v.loewis.de wrote: Someone with web server access may want to double check the modification dates of the .txt files relative to the generated .html files for other PEPs though. make will deal with that just fine. If a PEP was modified, svn up will update the time stamp on the file. When then the rebuild fails, the html file will still have an old time stamp. So I'm unsure why you thought you needed to modify some of the files. Because it's not clear to most of us on this thread what the failure modes and recovery strategies are? I know it's clear as mud to me how to debug these kinds of issues. Yep, it was just a misunderstanding on my part as to possible failure modes for the PEP publication process. I've certainly seen plenty of other systems which need to be resent events if processing of the original events fails. Primarily, I didn't know that any PEP commit just triggered a full Makefile invocation for the PEP directory rather than trying to be selective. (Letting make sort it out is a better idea, I just didn't know it was set up that way). (And, like Terry, Firefox chokes on the postcommit log for me. The file appears to be too big for my system to handle gracefully, so checking it really didn't help me. I did try though.) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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] [Web-SIG] WSGI is now Python 3-friendly
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 preface is littered with unnecessary links, because the PEP pre-processor turns *every* mere textual mention of a PEP into a link to it. Ouch. This is about as annoying as Thunderbird's message editor 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. -- Terry Jan Reedy ___ 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] [Web-SIG] WSGI is now Python 3-friendly
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 happens without any special markup. Currently, the PEP preface is littered with unnecessary links, because the PEP pre-processor turns *every* mere textual mention of a PEP into a link to it. Ouch. This is about as annoying as Thunderbird's message editor 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. ___ 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] [Web-SIG] WSGI is now Python 3-friendly
The PEP still hasn't showed up on Python.org, though, so I'm wondering if maybe I broke something else somewhere. See http://www.python.org/status/postcommitlog.txt Error processing PEP None (./pep-.txt), excluding: (./pep-.txt): did not deal with u'Replaces' before having to handle 'Created' make: *** [pep-.txt] Error 1 svn up make pep-.txt Traceback (most recent call last): File /data/website-build/build/scripts/post-commit-svnup.py, line 160, in ? main() File /data/website-build/build/scripts/post-commit-svnup.py, line 139, in main cmd(make pep-.txt) File /data/website-build/build/scripts/post-commit-svnup.py, line 35, in cmd raise RuntimeError, '%s failed w/ exit code %d' % (command, err) RuntimeError: make pep-.txt failed w/ exit code 512 make: Circular pep-.txt - pep-.txt dependency dropped. 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] [Web-SIG] WSGI is now Python 3-friendly
On 9/27/2010 2:22 PM, Martin v. Löwis wrote: The PEP still hasn't showed up on Python.org, though, so I'm wondering if maybe I broke something else somewhere. See http://www.python.org/status/postcommitlog.txt Nasty link. That log begins back in 2008 and is so huge that it was still loading after about 20 seconds when I stopped it. Methinks it should periodically be archived into a separate file so it stays a manageable size. -- Terry Jan Reedy ___ 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] [Web-SIG] WSGI is now Python 3-friendly
On 27/09/2010 18:22, 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 happens without any special markup. Currently, the PEP preface is littered with unnecessary links, because the PEP pre-processor turns *every* mere textual mention of a PEP into a link to it. Ouch. This is about as annoying as Thunderbird's message editor 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. I'd normally send this type of email off-list, but if I send it on list then hopefully you don't get twenty other emails saying the same thing... If you don't like Thunderbird warning you about attaching files then switch that off! Preferences - Composition - Check for missing attachments All the best, Michael Foord 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. -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ 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] [Web-SIG] WSGI is now Python 3-friendly
All fixed. On Mon, Sep 27, 2010 at 11:22, Martin v. Löwis mar...@v.loewis.de wrote: The PEP still hasn't showed up on Python.org, though, so I'm wondering if maybe I broke something else somewhere. See http://www.python.org/status/postcommitlog.txt Error processing PEP None (./pep-.txt), excluding: (./pep-.txt): did not deal with u'Replaces' before having to handle 'Created' make: *** [pep-.txt] Error 1 svn up make pep-.txt Traceback (most recent call last): File /data/website-build/build/scripts/post-commit-svnup.py, line 160, in ? main() File /data/website-build/build/scripts/post-commit-svnup.py, line 139, in main cmd(make pep-.txt) File /data/website-build/build/scripts/post-commit-svnup.py, line 35, in cmd raise RuntimeError, '%s failed w/ exit code %d' % (command, err) RuntimeError: make pep-.txt failed w/ exit code 512 make: Circular pep-.txt - pep-.txt dependency dropped. 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/brett%40python.org ___ 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] [Web-SIG] WSGI is now Python 3-friendly
At 12:36 PM 9/27/2010 -0700, Brett Cannon wrote: All fixed. Nope. I mean, sure, I checked in fixed PEP sources several hours ago, but python.org still doesn't show PEP , or the updated version of PEP 333. ___ 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] [Web-SIG] WSGI is now Python 3-friendly
I spoke too soon. The Makefile stopped complaining before I committed, but turned out that was a lie. Fixed PEP 0 again, verifying there were no errors after a `make clean`, touching pep-.txt, or from just deleting pep-.txt. On Mon, Sep 27, 2010 at 13:33, P.J. Eby p...@telecommunity.com wrote: At 12:36 PM 9/27/2010 -0700, Brett Cannon wrote: All fixed. Nope. I mean, sure, I checked in fixed PEP sources several hours ago, but python.org still doesn't show PEP , or the updated version of PEP 333. ___ 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] [Web-SIG] WSGI is now Python 3-friendly
Am 27.09.2010 22:33, schrieb P.J. Eby: At 12:36 PM 9/27/2010 -0700, Brett Cannon wrote: All fixed. Nope. I mean, sure, I checked in fixed PEP sources several hours ago, but python.org still doesn't show PEP , or the updated version of PEP 333. It does now, for me, so I assume someone's gone and prodded it. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ 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] [Web-SIG] WSGI is now Python 3-friendly
Am 27.09.2010 22:17, schrieb P.J. Eby: At 12:36 PM 9/27/2010 -0700, Brett Cannon wrote: All fixed. Nope. Indeed. The immediate problem was that genpepindex tried to read pep-, and didn't like it. I worked around that in r85041, so that genpepindex now skips over pep-.txt. However, if it's really important that the fields in a PEP are in a certain order (why is that important?), then I guess PEP 0 should really comply with its own specification :-) 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] [Web-SIG] WSGI is now Python 3-friendly
On Tue, Sep 28, 2010 at 6:33 AM, P.J. Eby p...@telecommunity.com wrote: At 12:36 PM 9/27/2010 -0700, Brett Cannon wrote: All fixed. Nope. I mean, sure, I checked in fixed PEP sources several hours ago, but python.org still doesn't show PEP , or the updated version of PEP 333. I tweaked the post dates in the PEPs to try to kick the webserver into regenerating them when I committed the updated versions, and Brett and Martin have been tinkering with the PEP 0 generation code. Something or other in that process triggered a proper rebuild, since the updated PEP 333 and PEP are now visible on the site. Someone with web server access may want to double check the modification dates of the .txt files relative to the generated .html files for other PEPs though. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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] [Web-SIG] WSGI is now Python 3-friendly
On Mon, Sep 27, 2010 at 1:33 PM, P.J. Eby p...@telecommunity.com wrote: At 12:36 PM 9/27/2010 -0700, Brett Cannon wrote: All fixed. Nope. I mean, sure, I checked in fixed PEP sources several hours ago, but python.org still doesn't show PEP , or the updated version of PEP 333. Seems Brett has fixed it. Both PEPs are now online. I wonder if it would make sense to change both from Informational to Standard Track ? -- --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] [Web-SIG] WSGI is now Python 3-friendly
Someone with web server access may want to double check the modification dates of the .txt files relative to the generated .html files for other PEPs though. make will deal with that just fine. If a PEP was modified, svn up will update the time stamp on the file. When then the rebuild fails, the html file will still have an old time stamp. So I'm unsure why you thought you needed to modify some of the files. 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] [Web-SIG] WSGI is now Python 3-friendly
On Mon, Sep 27, 2010 at 2:21 PM, Martin v. Löwis mar...@v.loewis.de wrote: Someone with web server access may want to double check the modification dates of the .txt files relative to the generated .html files for other PEPs though. make will deal with that just fine. If a PEP was modified, svn up will update the time stamp on the file. When then the rebuild fails, the html file will still have an old time stamp. So I'm unsure why you thought you needed to modify some of the files. Because it's not clear to most of us on this thread what the failure modes and recovery strategies are? I know it's clear as mud to me how to debug these kinds of issues. -- --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] [Web-SIG] WSGI is now Python 3-friendly
At 02:03 PM 9/27/2010 -0700, Guido van Rossum wrote: On Mon, Sep 27, 2010 at 1:33 PM, P.J. Eby p...@telecommunity.com wrote: At 12:36 PM 9/27/2010 -0700, Brett Cannon wrote: All fixed. Nope. I mean, sure, I checked in fixed PEP sources several hours ago, but python.org still doesn't show PEP , or the updated version of PEP 333. Seems Brett has fixed it. Both PEPs are now online. I wonder if it would make sense to change both from Informational to Standard Track ? From PEP 1: There are three kinds of PEP: * A Standards Track PEP describes a new feature or implementation for Python. * An Informational PEP describes a Python design issue, or provides general guidelines or information to the Python community, but does not propose a new feature. Informational PEPs do not necessarily represent a Python community consensus or recommendation, so users and implementors are free to ignore Informational PEPs or follow their advice. * A Process PEP describes a process surrounding Python, or proposes a change to (or an event in) a process. Process PEPs are like Standards Track PEPs but apply to areas other than the Python language itself. They may propose an implementation, but not to Python's codebase; they often require community consensus; unlike Informational PEPs, they are more than recommendations, and users are typically not free to ignore them. Examples include procedures, guidelines, changes to the decision-making process, and changes to the tools or environment used in Python development. Any meta-PEP is also considered a Process PEP. I don't think it qualifies as a Standards PEP under the above definitions. I made it Informational originally because it's rather like the DB API PEPs, which are Informational. I suppose we could say it's a Process PEP, or perhaps update PEP 1 to add a new category (into which the DB API PEPs would also fall), or maybe just tweak the above definitions a bit so that the Informational category makes more sense. ___ 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] [Web-SIG] WSGI is now Python 3-friendly
On Mon, Sep 27, 2010 at 4:29 PM, P.J. Eby p...@telecommunity.com wrote: At 02:03 PM 9/27/2010 -0700, Guido van Rossum wrote: On Mon, Sep 27, 2010 at 1:33 PM, P.J. Eby p...@telecommunity.com wrote: At 12:36 PM 9/27/2010 -0700, Brett Cannon wrote: All fixed. Nope. I mean, sure, I checked in fixed PEP sources several hours ago, but python.org still doesn't show PEP , or the updated version of PEP 333. Seems Brett has fixed it. Both PEPs are now online. I wonder if it would make sense to change both from Informational to Standard Track ? From PEP 1: There are three kinds of PEP: * A Standards Track PEP describes a new feature or implementation for Python. * An Informational PEP describes a Python design issue, or provides general guidelines or information to the Python community, but does not propose a new feature. Informational PEPs do not necessarily represent a Python community consensus or recommendation, so users and implementors are free to ignore Informational PEPs or follow their advice. * A Process PEP describes a process surrounding Python, or proposes a change to (or an event in) a process. Process PEPs are like Standards Track PEPs but apply to areas other than the Python language itself. They may propose an implementation, but not to Python's codebase; they often require community consensus; unlike Informational PEPs, they are more than recommendations, and users are typically not free to ignore them. Examples include procedures, guidelines, changes to the decision-making process, and changes to the tools or environment used in Python development. Any meta-PEP is also considered a Process PEP. I don't think it qualifies as a Standards PEP under the above definitions. I made it Informational originally because it's rather like the DB API PEPs, which are Informational. I suppose we could say it's a Process PEP, or perhaps update PEP 1 to add a new category (into which the DB API PEPs would also fall), or maybe just tweak the above definitions a bit so that the Informational category makes more sense. Hm. I would rather extend the definition of Standards Track to include API standards that are important to the community even if they do not introduce a new feature for the language or standard library. WSGI and DB-API being the two most well-known examples but I wouldn't be surprised if there were others, possibly in the NumPy world. -- --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] [Web-SIG] WSGI is now Python 3-friendly
On 9/26/2010 9:38 PM, P.J. Eby wrote: Currently, the PEP preface is littered with unnecessary links, because the PEP pre-processor turns *every* mere textual mention of a PEP into a link to it. Perhaps the preprocessor should only do this for the first occurrence of each linkable phrase in a paragraph? -- Greg ___ 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] [Web-SIG] WSGI is now Python 3-friendly
At 05:41 PM 9/27/2010 -0700, Guido van Rossum wrote: On Mon, Sep 27, 2010 at 4:29 PM, P.J. Eby p...@telecommunity.com wrote: At 02:03 PM 9/27/2010 -0700, Guido van Rossum wrote: On Mon, Sep 27, 2010 at 1:33 PM, P.J. Eby p...@telecommunity.com wrote: At 12:36 PM 9/27/2010 -0700, Brett Cannon wrote: All fixed. Nope. I mean, sure, I checked in fixed PEP sources several hours ago, but python.org still doesn't show PEP , or the updated version of PEP 333. Seems Brett has fixed it. Both PEPs are now online. I wonder if it would make sense to change both from Informational to Standard Track ? From PEP 1: There are three kinds of PEP: * A Standards Track PEP describes a new feature or implementation for Python. * An Informational PEP describes a Python design issue, or provides general guidelines or information to the Python community, but does not propose a new feature. Informational PEPs do not necessarily represent a Python community consensus or recommendation, so users and implementors are free to ignore Informational PEPs or follow their advice. * A Process PEP describes a process surrounding Python, or proposes a change to (or an event in) a process. Process PEPs are like Standards Track PEPs but apply to areas other than the Python language itself. They may propose an implementation, but not to Python's codebase; they often require community consensus; unlike Informational PEPs, they are more than recommendations, and users are typically not free to ignore them. Examples include procedures, guidelines, changes to the decision-making process, and changes to the tools or environment used in Python development. Any meta-PEP is also considered a Process PEP. I don't think it qualifies as a Standards PEP under the above definitions. I made it Informational originally because it's rather like the DB API PEPs, which are Informational. I suppose we could say it's a Process PEP, or perhaps update PEP 1 to add a new category (into which the DB API PEPs would also fall), or maybe just tweak the above definitions a bit so that the Informational category makes more sense. Hm. I would rather extend the definition of Standards Track to include API standards that are important to the community even if they do not introduce a new feature for the language or standard library. WSGI and DB-API being the two most well-known examples but I wouldn't be surprised if there were others, possibly in the NumPy world. Well, one of the tradeoffs here is that Informational track allows something to grow into a solid standard without also having to pass the same level of up-front scrutiny and commitment that a Standards track item does. I rather doubt that either the DBAPI *or* WSGI would've passed that scrutiny in early days, and the free to ignore part means that there's a lot less pushback on the minor points than generally occurs with Standards track PEPs. So, I'd hate for us to lose out on the *next* DBAPI or WSGI due to an implied pressure of needing to get it right in the first place. (Indeed, I think we need *more* Informational PEPs -- in retrospect there was probably some point at which I should have done some relating to setuptools and eggs and such.) Overall, though, I supposed there's no problem with promoting Final Informational PEPs to Standards, *unless* it creates an expectation that Informational PEPs will become Standards and they thus end up being debated in the same way anyway. (Of course, if it generally takes five or six years before an Informational PEP usually gets promoted, this is unlikely to be a major worry.) ___ 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] [Web-SIG] WSGI is now Python 3-friendly
Because it's not clear to most of us on this thread what the failure modes and recovery strategies are? I know it's clear as mud to me how to debug these kinds of issues. As a starting point, look at the postcommitlog. It should contain the commands that got executed, and the error messages that got generated. 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] [Web-SIG] WSGI is now Python 3-friendly
Well, one of the tradeoffs here is that Informational track allows something to grow into a solid standard without also having to pass the same level of up-front scrutiny and commitment that a Standards track item does. I rather doubt that either the DBAPI *or* WSGI would've passed that scrutiny in early days, and the free to ignore part means that there's a lot less pushback on the minor points than generally occurs with Standards track PEPs. The downside of an informational PEP is that it is unilateral. The author can put anything into it, and the community doesn't really get a voice in deciding on it. It's bad for quality (as I think you also point out) if the author of a PEP is also the one who pronounces on it. 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] [Web-SIG] WSGI is now Python 3-friendly
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 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.) ___ 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] [Web-SIG] WSGI is now Python 3-friendly
On 9/26/2010 1:33 PM, P.J. Eby wrote: Thank you do doing the needed rewrite. Can we make it PEP , 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 ___ 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] [Web-SIG] WSGI is now Python 3-friendly
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 , then? ;-) That works for me. -Barry ___ 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] [Web-SIG] WSGI is now Python 3-friendly
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 , then? ;-) That works for me. Go for it. -- --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] [Web-SIG] WSGI is now Python 3-friendly
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 , 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? ___ 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] [Web-SIG] WSGI is now Python 3-friendly
On Mon, Sep 27, 2010 at 6:56 AM, Guido van Rossum gu...@python.org wrote: Since you have commit privileges, just do it. The PEP editor position 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 for further information on Python 3 compliance or some such words. Add a similar note at the top of PEP -- maybe mark up the differences in PEP so people can easily tell what was added. And move PEP 333 to Final status. Since PEP 333 is referred to as both by both its PEP number and as WSGI 1.0, should the new PEP explicitly state that PEP is WSGI 1.0.1? (i.e. not a full update, even to 1.1 status, just some small tweaks to make it usable in the Python 3 world along with some generally applicable clarifications). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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] [Web-SIG] WSGI is now Python 3-friendly
Done. The other amendments were never actually made, so I just reverted the Python 3 bit after moving it to the new PEP. I'll make the changes to instead as soon as I have another time slot free. At 01:56 PM 9/26/2010 -0700, Guido van Rossum wrote: Since you have commit privileges, just do it. The PEP editor position 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 for further information on Python 3 compliance or some such words. Add a similar note at the top of PEP -- 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 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 , 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) ___ 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/pje%40telecommunity.com ___ 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] [Web-SIG] WSGI is now Python 3-friendly
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 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. ;-) ) ___ 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] [Web-SIG] WSGI is now Python 3-friendly
At 11:15 AM 9/27/2010 +1000, Ben Finney wrote: P.J. Eby http://mail.python.org/mailman/listinfo/python-devpje 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 preface is littered with unnecessary links, because the PEP pre-processor turns *every* mere textual mention of a PEP into a link to it. ___ 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] [Web-SIG] WSGI is now Python 3-friendly
P.J. Eby p...@telecommunity.com writes: At 11:15 AM 9/27/2010 +1000, Ben Finney wrote: 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. […] Right, I misread. Sorry for the noise. -- \“Beware of bugs in the above code; I have only proved it | `\ correct, not tried it.” —Donald Knuth, 1977-03-29 | _o__) | Ben Finney ___ 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
