Mailman 3 September 2010 - Python-Dev

Atlassian and bitbucket merge
by Steve Holden Sept. 29, 2010

Sept. 29, 2010

I see that Atlassian have just taken over BitBucket, the Mercurial hosting company. IIRC Atlassian offered to host our issue tracking on JIRA, but in the end we decided to eat our own dog food and went with roundup. I'm wondering if they'd be similarly interested in supporting our Hg server. Or is self-hosting the only acceptable solution? From recent mail it looks likes we may be up and running on Hg fairly soon. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 … [View More]

15 18

Re: [Python-Dev] [Python-checkins] r85101 - in python/branches/py3k/Doc/library: http.client.rst urllib.request.rst
by Eric Smith Sept. 29, 2010

Sept. 29, 2010

On 9/29/2010 7:24 AM, antoine.pitrou wrote: > Modified: python/branches/py3k/Doc/library/urllib.request.rst > ============================================================================== > --- python/branches/py3k/Doc/library/urllib.request.rst (original) > +++ python/branches/py3k/Doc/library/urllib.request.rst Wed Sep 29 13:24:21 2010 > @@ -11,6 +11,10 @@ > opening URLs (mostly HTTP) in a complex world --- basic and digest > authentication, redirections, cookies … [View More]

1 0

Re: [Python-Dev] r85028 - in python/branches/py3k: Doc/c-api/init.rst Include/pythonrun.h Modules/getpath.c PC/getpathp.c
by Georg Brandl Sept. 29, 2010

Sept. 29, 2010

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/… [View More]

3 2

Prefetching on buffered IO files
by Antoine Pitrou Sept. 29, 2010

Sept. 29, 2010

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 … [View More]

3 3

issue2180 and using 'tokenize' with Python 3 'str's
by Meador Inge Sept. 29, 2010

Sept. 29, 2010

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/… [View More]

7 10

Re: [Python-Dev] [Web-SIG] WSGI is now Python 3-friendly
by P.J. Eby Sept. 28, 2010

Sept. 28, 2010

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 3333, or the updated version of PEP 333.

6 8

Re: [Python-Dev] [Web-SIG] WSGI is now Python 3-friendly
by P.J. Eby Sept. 28, 2010

Sept. 28, 2010

At 05:41 PM 9/27/2010 -0700, Guido van Rossum wrote: >On Mon, Sep 27, 2010 at 4:29 PM, P.J. Eby <pje(a)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 <pje(a)telecommunity.com> wrote: > >> > At 12:36 PM 9/27/2010 -0700, Brett Cannon wrote: > >> >> > >> >> All fixed. > >> > > >> > Nope. I mean, sure, I … [View More]checked in fixed PEP sources several hours ago, > >> > but > >> > python.org still doesn't show PEP 3333, 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.) [View Less]

2 1

Mark PEP 3148 as Final?
by Nick Coghlan Sept. 28, 2010

Sept. 28, 2010

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 | ncoghlan(a)gmail.com | Brisbane, Australia

2 1

Re: [Python-Dev] [Web-SIG] WSGI is now Python 3-friendly
by P.J. Eby Sept. 28, 2010

Sept. 28, 2010

At 02:03 PM 9/27/2010 -0700, Guido van Rossum wrote: >On Mon, Sep 27, 2010 at 1:33 PM, P.J. Eby <pje(a)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 3333, or the updated version of PEP 333. > >Seems Brett has fixed it. Both PEPs are now online. > >I wonder if … [View More]

2 1

Re: [Python-Dev] [Web-SIG] WSGI is now Python 3-friendly
by P.J. Eby Sept. 27, 2010

Sept. 27, 2010

At 08:20 AM 9/26/2010 -0700, Guido van Rossum wrote: >I'm happy approving Final status for the >*original* PEP 333 and I'm happy to approve a new PEP which includes >PJE's corrections. Can we make it PEP 3333, then? ;-) That 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 … [View More]

9 14