Mailman 3 June 2011 - Python-Dev

svn.python.org confusion
by Ned Deily June 30, 2011

June 30, 2011

Not surprisingly, people are still attempting to browse and/or checkout Python source from svn.python.org. They could be following out-of-date instructions from somewhere or might be expecting the svn repos are mirroring the hg ones. This causes wasted time and frustration for users and for us following up on issues. Could some text be added to the svn browser pages to at least indicate that the repo is no longer being updated with a link to the hg.python.org browser? I'm not sure … [View More]

9 10

Re: [Python-Dev] [Python-checkins] cpython: store the current scope on the stack right away
by Nick Coghlan June 30, 2011

June 30, 2011

On Thu, Jun 30, 2011 at 1:53 PM, benjamin.peterson <python-checkins(a)python.org> wrote: > http://hg.python.org/cpython/rev/151142c0c5b1 > changeset: 71087:151142c0c5b1 > parent: 71084:9aa3fcab76f0 > user: Benjamin Peterson <benjamin(a)python.org> > date: Wed Jun 29 22:52:39 2011 -0500 > summary: > store the current scope on the stack right away Heh, I was going to comment … [View More]

1 0

Re: [Python-Dev] [Python-checkins] cpython (2.7): Fixup repr for dict_proxy objects.
by Ezio Melotti June 30, 2011

June 30, 2011

Hi, On Thu, Jun 30, 2011 at 2:51 AM, raymond.hettinger < python-checkins(a)python.org> wrote: > http://hg.python.org/cpython/rev/9a0b6c07b488 > changeset: 71086:9a0b6c07b488 > branch: 2.7 > parent: 71055:cdfcd00873cd > user: Raymond Hettinger <python(a)rcn.com> > date: Thu Jun 30 00:44:36 2011 +0100 > summary: > Fixup repr for dict_proxy objects. > This was already fixed in a slightly different way in 3.x. Unless there's a … [View More]

2 1

speed.python.org machine online
by Jesse Noller June 29, 2011

June 29, 2011

I've posted a more expansive entry on my blog: http://jessenoller.com/2011/06/29/announcing-the-new-speed-python-org-machi… But the short version, that as discussed at the VM and language summit, we now have a hosted machine dedicated to the running of cross-interpreter speed tests, etc. The hardware was generously donate by HP and the hosting provided, again, free, by OSU/OSL. DL380 HP DL380G7 X5670 LFF (2U) Dual HP NC382i Dual Port Multifunction Gigabit Server Adapters HP Smart Array … [View More]

2 1

Re: [Python-Dev] [Python-checkins] cpython (3.2): Issue #12400: runtest() truncates the StringIO stream before a new test
by Victor Stinner June 29, 2011

June 29, 2011

Le mercredi 29 juin 2011 à 13:05 -0400, Terry Reedy a écrit : > On 6/29/2011 11:30 AM, victor.stinner wrote: > > > summary: > > Issue #12400: runtest() truncates the StringIO stream before a new test > > > > files: > > Lib/test/regrtest.py | 1 + > > 1 files changed, 1 insertions(+), 0 deletions(-) > > > > > > diff --git a/Lib/test/regrtest.py b/Lib/test/regrtest.py > > --- a/Lib/test/regrtest.py > > +++ b/Lib/… [View More]

1 0

Re: [Python-Dev] [Python-checkins] cpython: Issue #12400: fix test_faulthandler if regrtest captures sys.stderr
by Nick Coghlan June 29, 2011

June 29, 2011

On Wed, Jun 29, 2011 at 9:43 PM, victor.stinner <python-checkins(a)python.org> wrote: > http://hg.python.org/cpython/rev/80c7d63325f6 > changeset: 71065:80c7d63325f6 > user: Victor Stinner <victor.stinner(a)haypocalc.com> > date: Wed Jun 29 13:44:05 2011 +0200 > summary: > Issue #12400: fix test_faulthandler if regrtest captures sys.stderr > > faulthandler.enable() requires that sys.stderr has … [View More]

1 0

open(): set the default encoding to 'utf-8' in Python 3.3?
by Victor Stinner June 29, 2011

June 29, 2011

In Python 2, open() opens the file in binary mode (e.g. file.readline() returns a byte string). codecs.open() opens the file in binary mode by default, you have to specify an encoding name to open it in text mode. In Python 3, open() opens the file in text mode by default. (It only opens the binary mode if the file mode contains "b".) The problem is that open() uses the locale encoding if the encoding is not specified, which is the case *by default*. The locale encoding can be: - UTF-8 on … [View More]Mac OS X, most Linux distributions - ISO-8859-1 os some FreeBSD systems - ANSI code page on Windows, e.g. cp1252 (close to ISO-8859-1) in Western Europe, cp952 in Japan, ... - ASCII if the locale is manually set to an empty string or to "C", or if the environment is empty, or by default on some systems - something different depending on the system and user configuration... If you develop under Mac OS X or Linux, you may have surprises when you run your program on Windows on the first non-ASCII character. You may not detect the problem if you only write text in english... until someone writes the first letter with a diacritic. As discussed before on this list, I propose to set the default encoding of open() to UTF-8 in Python 3.3, and add a warning in Python 3.2 if open() is called without an explicit encoding and if the locale encoding is not UTF-8. Using the warning, you will quickly notice the potential problem (using Python 3.2.2 and -Werror) on Windows or by using a different locale encoding (.e.g using LANG="C"). I expect a lot of warnings from the Python standard library, and as many in third party modules and applications. So do you think that it is too late to change that in Python 3.3? One argument for changing it directly in Python 3.3 is that most users will not notice the change because their locale encoding is already UTF-8. An alternative is to: - Python 3.2: use the locale encoding but emit a warning if the locale encoding is not UTF-8 - Python 3.3: use UTF-8 and emit a warning if the locale encoding is not UTF-8... or maybe always emit a warning? - Python 3.3: use UTF-8 (but don't emit warnings anymore) I don't think that Windows developer even know that they are writing files into the ANSI code page. MSDN documentation of WideCharToMultiByte() warns developer that the ANSI code page is not portable, even accross Windows computers: "The ANSI code pages can be different on different computers, or can be changed for a single computer, leading to data corruption. For the most consistent results, applications should use Unicode, such as UTF-8 or UTF-16, instead of a specific code page, unless legacy standards or data formats prevent the use of Unicode. If using Unicode is not possible, applications should tag the data stream with the appropriate encoding name when protocols allow it. HTML and XML files allow tagging, but text files do not." It will always be possible to use ANSI code page using encoding="mbcs" (only work on Windows), or an explicit code page number (e.g. encoding="cp2152"). -- The two other (rejetected?) options to improve open() are: - raise an error if the encoding argument is not set: will break most programs - emit a warning if the encoding argument is not set -- Should I convert this email into a PEP, or is it not required? Victor [View Less]

16 36

PEP 380 acceptance (was Re: EuroPython Language Summit report)
by Nick Coghlan June 28, 2011

June 28, 2011

On Sun, Jun 26, 2011 at 2:44 AM, Guido van Rossum <guido(a)python.org> wrote: > Let me cut this short. PEP 380 is pretty much approved. I know there > are a few details worth quibbling over, but they are not going to > jeopardize acceptance of the PEP. We are waiting for an implementation > in Python 3.3. In fact, I wouldn't mind at this point if someone took > their best effort at an implementation and checked it into the 3.3 > branch, and we can do the quibbling over … [View More]

2 4

EuroPython Language Summit report
by Mark Dickinson June 28, 2011

June 28, 2011

EuroPython 2011 Language Summit =============================== Here's a brief report on the EuroPython 2011 Language Summit, held on Sunday 19 June, 2011 in Florence. It was a fairly small meeting, with a lot of informal and loosely-focused discussion and few conclusions reached. I've outlined the topics that we discussed below. Present: Antonio Cuni Mark Dickinson Larry Hastings (chair) Marc-André Lemburg Ezio Melotti Antoine Pitrou Armin Ronacher Armin … [View More]Rigo Mark Ramm Topics covered ============== Python 3 adoption ----------------- This was a long and wide-ranging discussion on the general state of Python 3 adoption. Some highlights: - Even amongst those present at the meeting, most are still using Python 2 for everyday work. - pypy: no definitive plans yet for PyPy supporting Python 3. - The web community is still very much focused on Python 2. - There's ongoing work (or perhaps just discussion?) on being able to generate Python 3 documentation using Sphinx running on Python 3. This would be particularly useful when using extensions like 'autodoc' for Python 3 code. - [Armin Ronacher] Python 3's Unicode support still has some dark areas. One example: when opening a text file for reading and writing, the default encoding used depends on the platform and on various environment variables. - Regular expression support in Python 3 needs improvement (support for Unicode character classes is a particular need). [Subtopic: what needs to be done to get the new regex module into Python? Should it replace the existing module? What about backwards compatibility issues?] - 2to3: It's still painful to upgrade a codebase from Python 2 to Python 3, and there doesn't seem to be a consensus on best practices yet. There was a long discussion that I can't hope to do justice to on whether 2to3 should be part of the standard library or not. (With side discussions on distutils and packaging in Python 3.) Armin Ronacher was one of the main participants in this discussion (and IIUC, the main opponent of having 2to3 in the standard library); Armin, do you want to summarize this? Another major topic of discussion was on how to manage Python 2 and Python 3 in plugin environments (e.g., Blender): is there some way that both Python 2 and Python 3 plugins could be used within the same system? This got a bit technical; perhaps someone else at the meeting would like to elaborate on this? State of Python 3 on the web ---------------------------- Brief discussion. Summary: it's improving; better than before. We have CherryPy and WSGI. There are issues in WSGI that are going to become more apparent as more people move to Python 3 frameworks. Discussion of open PEPS ----------------------- PEP 3151: (Reworking the OS and IO exception hierarchy.) Antoine summarized this; no real discussion here. PEP 3118: (Not open, but ...) Revising the buffer protocol. The buffer protocol implementation is still buggy and incomplete. (Mostly okay for 1d buffers, not even close for higher-dimensional work.) PEP 397: Python launcher for Windows. (This was actually discussed later, after lunch; apologies for messing with the timeline here.) There was some confusion over the purpose of this PEP. Armin Ronacher had some objections to the PEP in its current form, but it's not clear to me what those objects are, or whether they still exist. Armin, care to elaborate? PEP 0380: Syntax for delegating to a subgenerator. PEP 3150: Statement local namespaces. PEP 3152: Cofunctions. For all three of the above PEPs, there was some feeling that additional syntax changes to the language are unnecessary and make it harder to learn; where possible, we should prefer using 3rd partly libraries. Issue 12326 (Linux 3) --------------------- >From the issue report by Charles-François Natali:: Linus recently decided that the next Linux kernel version would 3.0 [1]. As a consequence, sys.platform (which is actually MACHDEP) will be 'linux3' on machines running Linux 3 kernels, and tests checking explicitely against 'linux2' will either break and won't run. There was significant discussion on how this should be solved. While there's a lot of discussion already on the tracker, the choice of solution may have significant ramifications, so it seems a good idea that this be discussed more widely on python-dev. Major questions:: - what should be done with Python 2.7? As it stands, as I understand it, sys.platform *will* become 'linux3' on Linux 3.x (it's a computed value somewhere) in Python 2.7.2, and since Python 2.7.2 is already out there we can't change that. Some of the proposed solutions to the issue would involve sys.platform changing between Python 2.7.2 and Python 2.7.3; is such a change acceptable for a bugfix release? - it's easy to fix up all uses of "== 'linux2' " in the standard library; is it okay to just let 3rd party code break here? - What should be done about Lib/plat-linux2? The rough consensus at the summit was that for Python 2.7 at least, the only realistic solution seems to be to do nothing except document the problem, and point people to the platform module. I'm not sure if this answers the Lib/plat-linux2 question. Python 2.7 ---------- How long will this be maintained? Original decision was 5 years. PyPI on EC2 ----------- There was some discussion several months ago about the possibility of hosting PyPI on EC2. Is this still something that should be considered? PyPI seems to have been much more problem free in recent times. virtualenv in Python 3.3? ------------------------- Apparently there was some discussion at the last PyCon about the possibility of virtualenv going into Python 3.3. As far as I know there's currently no open tracker item or PEP for this. Larry Hastings knows more here. -- Update from Larry: """I'm supportive of putting it in in 3.3, and I'm sitting with Raymond Hettinger right now and he supports it too. So I think if we get a working implementation it'll go in. It's under heavy discussion in c.l.p-d so I gather it's moving forward. Last I knew it was Carl Meyer pushing it forward, but Vinay Sanjip is the current standard-bearer. I understand Windows support will be a bit tricky; I don't know if they have someone who's going to handle it for them.""" Python website -------------- The Python website is painful to edit right now. [View Less]

13 21

Snow Leopard buildbot failing again...
by Bill Janssen June 28, 2011

June 28, 2011

I see that parc-snowleopard-1 went down again. I've done a software update, rebooted, and installed the latest buildslave, 0.8.4. I can ping dinsdale.python.org successfully from the machine. However, when I start the buildslave, I get this: $ buildslave start ~/buildarea/ /Library/Python/2.6/site-packages/Twisted-8.2.0-py2.6-macosx-10.6-universal.egg/twisted/internet/_sslverify.py:5: DeprecationWarning: the md5 module is deprecated; use hashlib instead import itertools, md5 Following … [View More]

5 7