Re: [Python-Dev] Python wiki
On Sun, Sep 26, 2010 at 03:53:58PM +0200, Georg Brandl wrote: * redirect from wiki.python.org to wiki.python.org/moin I've added a meta http-equiv element to the top page of wiki.python.org, so browsers will now jump to the /moin/ page immediately. This won't help crawlers that don't parse the HTML, but that probably doesn't matter. --amk ___ 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] hg conversion: tags
Am 26.09.2010 12:55, schrieb Dirkjan Ochtman: Hi all, I've recently been working on the conversion more (since my thesis got finished). I finally wrote the script that splits the release branches from the feature branches, so that we can include the former in the main repository and keep the latter in separate clones as needed. Next, I wanted to look into tags. There's a big list of tags (see below), and I wonder if I should clean that up or if we should leave it as-is. For example, it might be interesting to bring old release tags in line with newer tags (so Release_1_0 would become r10), or maybe use clean tags similar to what we do with hg itself (r266 would become just 2.6.6), or just remove some tags. Is this a good idea at all, or should we just leave everything the way it is now? I'd remove as many tags as makes sense, only keeping the release tags. Most others were made to quickly go back to a version before some change happened; however nobody would want to go back there anymore now. Just like my *-before-rstdocs tags, which I guess nobody ever used. As for how to call the releases, while I'd prefer a bit less cryptic names, keeping the rXYZ convention is fine with me. 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] r85028 - in python/branches/py3k: Doc/c-api/init.rst Include/pythonrun.h Modules/getpath.c PC/getpathp.c
Am 27.09.2010 07:32, schrieb kristjan.jonsson: Author: kristjan.jonsson Date: Mon Sep 27 07:32:54 2010 New Revision: 85028 Log: issue 9910 Add a Py_SetPath api to override magic path computations when starting up python. Modified: python/branches/py3k/Doc/c-api/init.rst python/branches/py3k/Include/pythonrun.h python/branches/py3k/Modules/getpath.c python/branches/py3k/PC/getpathp.c Modified: python/branches/py3k/Doc/c-api/init.rst +.. cfunction:: void Py_SetPath(const wchar_t *) + + .. index:: + triple: module; search; path + single: path (in module sys) + single: Py_GetPath() + + Set the default module search path. If this function is called before + :cfunc: `Py_Initialize` then :cfunc: Py_GetPath won't attempt to compute + a default serarch path but uses the provided one in stead. This is useful + if Python is being embedded by an application that has full knowledge + of the location of all modules. The path components should be separated + by semicolons. + + This also causes `sys.executable` to be set only to the raw program name + (see :cfunc:`Py_SetProgramName`) and `for sys.prefix` and + `sys.exec_prefix` to be empty. It is up to the caller to modify these if + required after calling :cfunc: `Py_Initialize`. + This needs a versionadded. 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] hg conversion: tags
On Sep 27, 2010, at 04:52 PM, Georg Brandl wrote: I'd remove as many tags as makes sense, only keeping the release tags. Most others were made to quickly go back to a version before some change happened; however nobody would want to go back there anymore now. Just like my *-before-rstdocs tags, which I guess nobody ever used. As for how to call the releases, while I'd prefer a bit less cryptic names, keeping the rXYZ convention is fine with me. We're still going to keep the Subversion repository in read-only even after the conversion. Will the mapping between svn and hg revision numbers be preserved somehow? If so, then I say in hg, nuke the tags we don't care about and sanitize the release tags to something that obvious and can't collide (e.g. r311 is 3.1.1 or 3.11? - yes despite Guido's Rule of Version Numbering). I'd personally be fine using the hexversion or even 3.1.1 as the tag name. Since we're going to live with the converted repository until the Next Big Thing In Version Control wink, let's take the opportunity now to clean things up and make them nice. I do think we should keep a mapping from new to old though. If that's not possible within the hg repository, can we at least generate a text file or some such and commit that? -Barry signature.asc Description: 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] hg conversion: tags
On Mon, Sep 27, 2010 at 17:28, Barry Warsaw ba...@python.org wrote: I do think we should keep a mapping from new to old though. If that's not possible within the hg repository, can we at least generate a text file or some such and commit that? I'm planning an extension so that at least the web interface will take r432432 and give you the corresponding hg changeset (if available!). Those who want it will also be able to install it in their local clones. Cheers, Dirkjan ___ 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] hg conversion: tags
On Mon, Sep 27, 2010 at 11:28 AM, Barry Warsaw ba...@python.org wrote: .. If so, then I say in hg, nuke the tags we don't care about and sanitize the release tags to something that obvious and can't collide (e.g. r311 is 3.1.1 or 3.11? - yes despite Guido's Rule of Version Numbering). I'd personally be fine using the hexversion or even 3.1.1 as the tag name. +1 Apart from being ambiguous, rXYZ notation conflicts with the tracker autoformat rule that links rNNN to svn revision. ___ 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] hg conversion: tags
On Mon, 27 Sep 2010 12:25:17 -0400 Alexander Belopolsky alexander.belopol...@gmail.com wrote: On Mon, Sep 27, 2010 at 11:28 AM, Barry Warsaw ba...@python.org wrote: .. If so, then I say in hg, nuke the tags we don't care about and sanitize the release tags to something that obvious and can't collide (e.g. r311 is 3.1.1 or 3.11? - yes despite Guido's Rule of Version Numbering). I'd personally be fine using the hexversion or even 3.1.1 as the tag name. +1 Apart from being ambiguous, rXYZ notation conflicts with the tracker autoformat rule that links rNNN to svn revision. And also, given that many hg commands can be specified a tag name using -rXXX, having to write -rr311 would be a bit awkward. ___ 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] Some changes to logging for 3.2
On 24/09/2010 12:06, Vinay Sajip wrote: http://plumberjack.blogspot.com/2010/09/improved-queuehandler-queuelistener.html Cool, how can I use it in Python 2.6? :-) 1. Copy the top part (imports, QueueHandler and QueueListener classes) from the Gist linked to in the article - http://gist.github.com/591699 - into a utility module you can use again and again. Thanks! Although my comment was a light hearted dig from my point of view that the components of the standard library should be separately packaged and a python distribution should just be a known good set of these packages... Were that the case, users of Python 2.5, 2.6 *and* 2.7 could benefit from your good work :-) cheers, Chris -- Simplistix - Content Management, Batch Processing Python Consulting - http://www.simplistix.co.uk ___ 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] Python wiki
On Mon, Sep 27, 2010 at 10:31 PM, A.M. Kuchling a...@amk.ca wrote: On Sun, Sep 26, 2010 at 03:53:58PM +0200, Georg Brandl wrote: * redirect from wiki.python.org to wiki.python.org/moin I've added a meta http-equiv element to the top page of wiki.python.org, so browsers will now jump to the /moin/ page immediately. This won't help crawlers that don't parse the HTML, but that probably doesn't matter. That did the trick, thanks. 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] Python wiki
Hello Le 25/09/2010 10:20, anatoly techtonik a écrit : On Fri, Sep 24, 2010 at 1:27 AM, Nick Coghlan ncogh...@gmail.com wrote: That's a good point actually... why *isn't* there a pydotorg-wiki-sig? (Aside from the obvious point of nobody ever asking for one). Because Yet Another Mailing List doesn't solve the problem. If you need one - go Google Groups like packaging folks did. Python ML are: 1. require dedicated admin to update, who is not a member of the group 2. don't have search 3. don't have optional thread subscription That's already enough to seek better platform for collaboration. This is debatable. Google Groups require a Google account, are not controlled by python-dev, require JavaScript to view the archives, don’t send MIME digests. The public archives for python.org MLs are indexed by Web search engines and are therefore searchable. Re: thread subscription, there is a setting about topics in the mailman admin but I don’t understand it. I suppose a good email client can do something equivalent. Community can perfectly manage the stuff without dedicated admins if there is a gameplay in it. I don’t agree with the split between admins and community. Admins are just trusted people from the community (which includes python-dev). My advice - subscribe people editing page by default (a checkbox near submit button). +1 wholeheartedly. With an admin team behind it, you can also make more use of ACLs to flag certain parts of the wiki as official by making them only editable by certain people I don’t know if this would be noticed enough to change the image of the wiki. I had started reviewing and updating all pages pertaining to distutils and distutils2 some months ago, and I viewed the wiki as a collaborative area to hash things out, before they can become official code or docs. Regards ___ 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] Python wiki
On Sep 27, 2010, at 10:36 PM, Éric Araujo wrote: Because Yet Another Mailing List doesn't solve the problem. If you need one - go Google Groups like packaging folks did. Python ML are: 1. require dedicated admin to update, who is not a member of the group 2. don't have search 3. don't have optional thread subscription That's already enough to seek better platform for collaboration. This is debatable. Google Groups require a Google account, are not controlled by python-dev, require JavaScript to view the archives, don’t send MIME digests. The public archives for python.org MLs are indexed by Web search engines and are therefore searchable. ObPlug: You can always read the archives at Gmane (e.g. via web or nntp) or mail-archive.com, both of which are searchable. Or you can help improve the world of open source mail archivers by getting involved in the Mailman project and helping us build the next generation archiver. :) -Barry signature.asc Description: 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] [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
[Python-Dev] Mark PEP 3148 as Final?
I saw the code for PEP 3148 go by on python-checkins the other day. Is there anything left to be done on that front, or can the PEP be marked Final? 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
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
[Python-Dev] Prefetching on buffered IO files
Hello, While trying to solve #3873 (poor performance of pickle on file objects, due to the overhead of calling read() with very small values), it occurred to me that the prefetching facilities offered by BufferedIOBase are not flexible and efficient enough. Indeed, if you use seek() and read(), 1) you limit yourself to seekable files 2) performance can be hampered by very bad seek() performance (this is true on GzipFile). If instead you use peek() and read(), the situation is better, but you end up doing multiple copies of data; also, you must call read() to advance the file pointer even though you don't care about the results. So I would propose adding the following method to BufferedIOBase: prefetch(self, buffer, skip, minread) Skip `skip` bytes from the stream. Then, try to read at least `minread` bytes and write them into `buffer`. The file pointer is advanced by at most `skip + minread`, or less if the end of file was reached. The total number of bytes written in `buffer` is returned, which can be more than `minread` if additional bytes could be prefetched (but, of course, cannot be more than `len(buffer)`). Arguments: - `buffer`: a writable buffer (e.g. bytearray) - `skip`: number of bytes to skip (must be = 0) - `minread`: number of bytes to read (must be = 0 and = len(buffer)) Also, the BufferedIOBase ABC can then provide default implementations of read(), readinto() and peek(), simply by calling prefetch(). (how read1() can fit into the picture is not obvious) What do you think? Regards Antoine. ___ 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] Prefetching on buffered IO files
On Mon, Sep 27, 2010 at 3:41 PM, Antoine Pitrou solip...@pitrou.net wrote: While trying to solve #3873 (poor performance of pickle on file objects, due to the overhead of calling read() with very small values), it occurred to me that the prefetching facilities offered by BufferedIOBase are not flexible and efficient enough. I haven't read the whole bug but there seem to be lots of different smaller issues there, right? It seems that one (unfortunate) constraint is that reading pickles cannot use buffered I/O (at least not on a non-seekable file) because the API has been documented to leave the file positioned right after the last byte of the pickled data, right? Indeed, if you use seek() and read(), 1) you limit yourself to seekable files 2) performance can be hampered by very bad seek() performance (this is true on GzipFile). Ow... I've always assumed that seek() is essentially free, because that's how a typical OS kernel implements it. If seek() is bad on GzipFile, how hard would it be to fix this? How common is the use case where you need to read a gzipped pickle *and* you need to leave the unzipped stream positioned exactly at the end of the pickle? If instead you use peek() and read(), the situation is better, but you end up doing multiple copies of data; also, you must call read() to advance the file pointer even though you don't care about the results. Have you measured how bad the situation is if you do implement it this way? So I would propose adding the following method to BufferedIOBase: prefetch(self, buffer, skip, minread) Skip `skip` bytes from the stream. Then, try to read at least `minread` bytes and write them into `buffer`. The file pointer is advanced by at most `skip + minread`, or less if the end of file was reached. The total number of bytes written in `buffer` is returned, which can be more than `minread` if additional bytes could be prefetched (but, of course, cannot be more than `len(buffer)`). Arguments: - `buffer`: a writable buffer (e.g. bytearray) - `skip`: number of bytes to skip (must be = 0) - `minread`: number of bytes to read (must be = 0 and = len(buffer)) I like the idea of an API that combines seek and read into a mutable buffer. However the semantics of this call seem really weird: there is no direct relationship between where it leaves the stream position and how much data it reads into the buffer. can you explain how exactly this will help solve the gzipped pickle performance problem? Also, the BufferedIOBase ABC can then provide default implementations of read(), readinto() and peek(), simply by calling prefetch(). (how read1() can fit into the picture is not obvious) What do you think? Move to python-ideas? -- --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 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] Python wiki
Éric Araujo writes: Le 25/09/2010 10:20, anatoly techtonik a écrit : Python ML are: 1. require dedicated admin to update, who is not a member of the group 2. don't have search 3. don't have optional thread subscription That's already enough to seek better platform for collaboration. This is debatable. Google Groups require a Google account, are not controlled by python-dev, require JavaScript to view the archives, don’t send MIME digests. The public archives for python.org MLs are indexed by Web search engines and are therefore searchable. Indeed. Mailman doesn't require a dedicated admin to operate, only to set up. Some things go better if you've got part-time admins (moderation in particular). I agree with techtonik that a better platform is apparently needed, but this is a client-server system, and the problem is in the client. Ie, he should upgrade his MUA to one that does threading properly, and allows priorities to be given to threads. (Emacs/Gnus is the one I'm familiar with but surely there are others.) This is a contextual judgment, not an absolute: apparently most Python devs *do* use sufficiently powerful MUAs for their purposes. It makes sense for the minority to adopt the majority practice. Re: thread subscription, there is a setting about topics in the mailman admin but I don’t understand it. Mailman topics are a clumsy Subject-based filter, and require admin intervention to set up. They're quite valuable for low-to-medium- traffic lists with a variety of more or less defined topics (ie, if there were more traffic, you'd want to split the list), but are pretty much useless for this purpose. Community can perfectly manage the stuff without dedicated admins if there is a gameplay in it. I don’t agree with the split between admins and community. Admins are just trusted people from the community (which includes python-dev). No, they're not just trusted people. They're trusted people with greater privilege than the rest of us, and therefore a bottleneck for some operations. My advice - subscribe people editing page by default (a checkbox near submit button). +1 wholeheartedly. That default needs to be user-configurable. I would not want to be spammed with typo corrections on a page where all I did was correct a typo. I probably wouldn't even want to see major changes by default: I came, I saw, I conquered the typo and got my info, now leave me alone! With an admin team behind it, you can also make more use of ACLs to flag certain parts of the wiki as official by making them only editable by certain people I don’t know if this would be noticed enough to change the image of the wiki. I had started reviewing and updating all pages pertaining to distutils and distutils2 some months ago, and I viewed the wiki as a collaborative area to hash things out, before they can become official code or docs. I don't think we want to change the image of the wiki (as in anybody can edit)! What we may want is (1) to make it easy for those with the authority to update the official docs (but there's a very good story for putting them in a repo, perhaps associated with the sources, so this is a weak argument for reference-docs-in-wiki), and (2) make it easy for readers to cross reference the community documentation (often more detailed or less intimidatingly formal) and the reference manuals. (1) *may* suggest using the wiki engine to support editing, but I think most devs are strongly against that. (2) suggests using the wiki engine to easily or even automatically set up cross-references. I think that wiki is probably the best technology for this purpose at the present time, but I don't know if it's worth the effort to make the official documentation wiki-friendly (in the sense of allowing the wiki to generate links to community documentation from the reference manuals). ___ 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] Mark PEP 3148 as Final?
On Mon, Sep 27, 2010 at 5:09 PM, Nick Coghlan ncogh...@gmail.com wrote: I saw the code for PEP 3148 go by on python-checkins the other day. Is there anything left to be done on that front, or can the PEP be marked Final? Cheers, Nick. Argh, yes :) ___ 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
[Python-Dev] Pronouncement needed in issue9675
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 http://bugs.python.org/issue9675 Long history sort: Python 2.7 backported Capsule support and (incorrectly, in my opinion) marked CObject as deprecated. All C modules in the stdlib were updated to Capsule (with a CObject compatibility layer), except BSDDB, because this change was done late in the cycle, the proposed patch was buggy (solvable) and a pronouncement was done that CObject was not actually deprecated. But in python 2.7 release, CObject is marked as deprecated (arg!), so when executing python with -We (mark warnings as errors), bsddb fails. Since I think that adopting Capsule in BSDDB for 2.7.1 would break the API compatibility (maybe the CObject proxy would solve this), and since a previous pronouncement was done abour CObject not-deprecated in 2.7.x, I would like comments. Long history and links to previous pronouncements in http://bugs.python.org/issue9675 My proposal: CObject should not be marked as deprecated in 2.7.1. Thanks for your time and attention. - -- Jesus Cea Avion _/_/ _/_/_/_/_/_/ j...@jcea.es - http://www.jcea.es/ _/_/_/_/ _/_/_/_/ _/_/ jabber / xmpp:j...@jabber.org _/_/_/_/ _/_/_/_/_/ . _/_/ _/_/_/_/ _/_/ _/_/ Things are not so easy _/_/ _/_/_/_/ _/_/_/_/ _/_/ My name is Dump, Core Dump _/_/_/_/_/_/ _/_/ _/_/ El amor es poner tu felicidad en la felicidad de otro - Leibniz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQCVAwUBTKFWeJlgi5GaxT1NAQLlIgP+NAOBvwCW8gJNFspsjdLc2VqPbwXK1GJc mmESVsoZRlAROwCkTlaOeO8GGoEuWtfb32SwJ+21RTPdPo7UxbaxhFUNju3bRYzQ We8VGh/Qu8oJPk/toifCEw80mv4Vr9Pfli3qsR9MmGsCBFdqjLMmtwTZAkl3uMoY 6PCdo1hgAoY= =veqL -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
[Python-Dev] issue2180 and using 'tokenize' with Python 3 'str's
Hi All, I was going through some of the open issues related to 'tokenize' and ran across 'issue2180'. The reproduction case for this issue is along the lines of: tokenize.tokenize(io.StringIO(if 1:\n \\\n #hey\n print 1).readline) but, with 'py3k' I get: tokenize.tokenize(io.StringIO(if 1:\n \\\n #hey\n print 1).readline) Traceback (most recent call last): File stdin, line 1, in module File /Users/minge/Code/python/py3k/Lib/tokenize.py, line 360, in tokenize encoding, consumed = detect_encoding(readline) File /Users/minge/Code/python/py3k/Lib/tokenize.py, line 316, in detect_encoding if first.startswith(BOM_UTF8): TypeError: Can't convert 'bytes' object to str implicitly which, as seen in the trace, is because the 'detect_encoding' function in 'Lib/tokenize.py' searches for 'BOM_UTF8' (a 'bytes' object) in the string to tokenize 'first' (a 'str' object). It seems to me that strings should still be able to be tokenized, but maybe I am missing something. Is the implementation of 'detect_encoding' correct in how it attempts to determine an encoding or should I open an issue for this? --- Meador ___ 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] issue2180 and using 'tokenize' with Python 3 'str's
2010/9/27 Meador Inge mead...@gmail.com: which, as seen in the trace, is because the 'detect_encoding' function in 'Lib/tokenize.py' searches for 'BOM_UTF8' (a 'bytes' object) in the string to tokenize 'first' (a 'str' object). It seems to me that strings should still be able to be tokenized, but maybe I am missing something. Is the implementation of 'detect_encoding' correct in how it attempts to determine an encoding or should I open an issue for this? Tokenize only works on bytes. You can open a feature request if you desire. -- Regards, Benjamin ___ 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] issue2180 and using 'tokenize' with Python 3 'str's
On 9/27/2010 11:27 PM, Benjamin Peterson wrote: 2010/9/27 Meador Inge mead...@gmail.com: which, as seen in the trace, is because the 'detect_encoding' function in 'Lib/tokenize.py' searches for 'BOM_UTF8' (a 'bytes' object) in the string to tokenize 'first' (a 'str' object). It seems to me that strings should still be able to be tokenized, but maybe I am missing something. Is the implementation of 'detect_encoding' correct in how it attempts to determine an encoding or should I open an issue for this? Tokenize only works on bytes. You can open a feature request if you desire. Working only on bytes does seem rather perverse. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 DjangoCon US September 7-9, 2010http://djangocon.us/ See Python Video! http://python.mirocommunity.org/ Holden Web LLC http://www.holdenweb.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
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
