Mailman 3 February 2015 - Python-checkins

cpython (3.4): Issue #23526: Fix ResourceWarning in test_httplib. Patch written by Alex Shkop.
by victor.stinner Feb. 27, 2015

Feb. 27, 2015

https://hg.python.org/cpython/rev/056d71d7bb28 changeset: 94771:056d71d7bb28 branch: 3.4 parent: 94769:d0e15d9cdd4b user: Victor Stinner <victor.stinner(a)gmail.com> date: Fri Feb 27 17:47:23 2015 +0100 summary: Issue #23526: Fix ResourceWarning in test_httplib. Patch written by Alex Shkop. files: Lib/test/test_httplib.py | 3 +++ Misc/ACKS | 1 + 2 files changed, 4 insertions(+), 0 deletions(-) diff --git a/Lib/test/test_httplib.py b/… [View More]

1 0

cpython (merge 3.4 -> default): Merge 3.4 (httplib)
by victor.stinner Feb. 27, 2015

Feb. 27, 2015

https://hg.python.org/cpython/rev/2701e36e692f changeset: 94772:2701e36e692f parent: 94770:344d57c521b9 parent: 94771:056d71d7bb28 user: Victor Stinner <victor.stinner(a)gmail.com> date: Fri Feb 27 17:47:40 2015 +0100 summary: Merge 3.4 (httplib) files: Lib/test/test_httplib.py | 3 +++ Misc/ACKS | 1 + 2 files changed, 4 insertions(+), 0 deletions(-) diff --git a/Lib/test/test_httplib.py b/Lib/test/test_httplib.py --- a/Lib/test/… [View More]

1 0

peps: a warning
by benjamin.peterson Feb. 27, 2015

Feb. 27, 2015

https://hg.python.org/peps/rev/b2d4457b9f07 changeset: 5715:b2d4457b9f07 user: Benjamin Peterson <benjamin(a)python.org> date: Fri Feb 27 10:29:03 2015 -0500 summary: a warning files: pep-0101.txt | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/pep-0101.txt b/pep-0101.txt --- a/pep-0101.txt +++ b/pep-0101.txt @@ -436,7 +436,8 @@ the script Doc/tools/dailybuild.py to point to the right stable/development branches, and to … [View More]

1 0

peps: Fix syntax error
by brett.cannon Feb. 27, 2015

Feb. 27, 2015

https://hg.python.org/peps/rev/fc626f4b1357 changeset: 5713:fc626f4b1357 user: Brett Cannon <brett(a)python.org> date: Fri Feb 27 09:34:48 2015 -0500 summary: Fix syntax error files: pep-0422.txt | 3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/pep-0422.txt b/pep-0422.txt --- a/pep-0422.txt +++ b/pep-0422.txt @@ -295,6 +295,8 @@ implicitly, but the decorator model makes such code much easier to understand and implement. +:: + class … [View More]

1 0

peps: Update PEP 11 to be more clear about what is required to gain support for a
by brett.cannon Feb. 27, 2015

Feb. 27, 2015

https://hg.python.org/peps/rev/00f5ef44638e changeset: 5714:00f5ef44638e user: Brett Cannon <brett(a)python.org> date: Fri Feb 27 09:35:12 2015 -0500 summary: Update PEP 11 to be more clear about what is required to gain support for a platform for CPython files: pep-0011.txt | 76 ++++++++++++++++++++++++++++++---------- 1 files changed, 57 insertions(+), 19 deletions(-) diff --git a/pep-0011.txt b/pep-0011.txt --- a/pep-0011.txt +++ b/pep-0011.txt @@ -2,51 +2,88 @… [View More]@ Title: Removing support for little used platforms Version: $Revision$ Last-Modified: $Date$ -Author: martin(a)v.loewis.de (Martin von Löwis) +Author: Martin von Löwis <martin(a)v.loewis.de>, + Brett Cannon <brett(a)python.org> Status: Active Type: Process Content-Type: text/x-rst Created: 07-Jul-2002 Post-History: 18-Aug-2007 + 16-May-2014 + 20-Feb-2015 Abstract -------- -This PEP documents operating systems (platforms) which are not -supported in Python anymore. For some of these systems, -supporting code might be still part of Python, but will be removed -in a future release - unless somebody steps forward as a volunteer -to maintain this code. +This PEP documents how an operating system (platform) becomes +supported in CPython and documents past support. Rationale --------- -Over time, the Python source code has collected various pieces of +Over time, the CPython source code has collected various pieces of platform-specific code, which, at some point in time, was considered necessary to use Python on a specific platform. Without access to this platform, it is not possible to determine whether this code is still needed. As a result, this code may -either break during the Python evolution, or it may become +either break during Python's evolution, or it may become unnecessary as the platforms evolve as well. The growing amount of these fragments poses the risk of unmaintainability: without having experts for a large number of platforms, it is not possible to determine whether a certain -change to the Python source code will work on all supported +change to the CPython source code will work on all supported platforms. -To reduce this risk, this PEP proposes a procedure to remove code -for platforms with no Python users. +To reduce this risk, this PEP specifies what is required for a +platform to be considered supported by Python as well as providing a +procedure to remove code for platforms with few or no Python +users. +Supporting platforms +-------------------- + +Gaining official platform support requires two things. First, a core +developer needs to volunteer to maintain platform-specific code. This +core developer can either already be a member of the Python +development team or be given contributor rights on the basis of +maintaining platform support (it is at the discretion of the Python +development team to decide if a person is ready to have such rights +even if it is just for supporting a specific platform). + +Second, a stable buildbot must be provided [2]_. This guarantees that +platform support will not be accidentally broken by a Python core +developer who does not have personal access to the platform. For a +buildbot to be considered stable it requires that the machine be +reliably up and functioning (but it is up to the Python core +developers to decide whether to promote a buildbot to being +considered stable). + +This policy does not disqualify supporting other platforms +indirectly. Patches which are not platform-specific but still done to +add platform support will be considered for inclusion. For example, +if platform-independent changes were necessary in the configure +script which were motivated to support a specific platform that could +be accepted. Patches which add platform-specific code such as the +name of a specific platform to the configure script will generally +not be accepted without the platform having official support. + +CPU architecture and compiler support are viewed in a similar manner +as platforms. For example, to consider the ARM architecture supported +a buildbot running on ARM would be required along with support from +the Python development team. In general it is not required to have +a CPU architecture run under every possible platform in order to be +considered supported. Unsupporting platforms ---------------------- -If a certain platform that currently has special code in it is -deemed to be without Python users, a note must be posted in this -PEP that this platform is no longer actively supported. This +If a certain platform that currently has special code in CPython is +deemed to be without enough Python users or lacks proper support from +the Python development team and/or a buildbot, a note must be posted +in this PEP that this platform is no longer actively supported. This note must include: - the name of the system @@ -62,15 +99,15 @@ condition (usually a preprocessor symbol) that will become unsupported. -At the same time, the Python source code must be changed to +At the same time, the CPython source code must be changed to produce a build-time error if somebody tries to install Python on this platform. On platforms using autoconf, configure must fail. This gives potential users of the platform a chance to step forward and offer maintenance. -Resupporting platforms ----------------------- +Re-supporting platforms +----------------------- If a user of a platform wants to see this platform supported again, he may volunteer to maintain the platform support. Such an @@ -87,7 +124,7 @@ support phase, where paid support is still available, and certain bug fixes are released (in particular security fixes). -Python's Windows support now follows this lifecycle. A new feature +CPython's Windows support now follows this lifecycle. A new feature release X.Y.0 will support all Windows releases whose extended support phase is not yet expired. Subsequent bug fix releases will support the same Windows releases as the original feature release (even if @@ -101,7 +138,7 @@ release is made. Developers of extension modules will generally need to use the same Visual Studio release; they are concerned both with the availability of the versions they need to use, and with keeping -the zoo of versions small. The Python source tree will keep +the zoo of versions small. The CPython source tree will keep unmaintained build files for older Visual Studio releases, for which patches will be accepted. Such build files will be removed from the source tree 3 years after the extended support for the compiler has @@ -223,6 +260,7 @@ ---------- .. [1] http://support.microsoft.com/lifecycle/ +.. [2] http://buildbot.python.org/3.x.stable/ Copyright --------- -- Repository URL: https://hg.python.org/peps [View Less]

1 0

devguide: Not an expert on anything anymore unfortunately
by hynek.schlawack Feb. 27, 2015

Feb. 27, 2015

https://hg.python.org/devguide/rev/f2a6631d8996 changeset: 730:f2a6631d8996 user: Hynek Schlawack <hs(a)ox.cx> date: Fri Feb 27 12:59:39 2015 +0100 summary: Not an expert on anything anymore unfortunately files: experts.rst | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/experts.rst b/experts.rst --- a/experts.rst +++ b/experts.rst @@ -197,7 +197,7 @@ selectors neologix, giampaolo.rodola shelve shlex -shutil … [View More]

1 0

Daily reference leaks (1bb9641713ec): sum=0
by solipsis＠pitrou.net Feb. 27, 2015

Feb. 27, 2015

results for 1bb9641713ec on branch "default" -------------------------------------------- Command line was: ['./python', '-m', 'test.regrtest', '-uall', '-R', '3:3:/home/antoine/cpython/refleaks/reflogJNvady', '-x']

1 0

Daily reference leaks (2eb99070a38f): sum=-3
by solipsis＠pitrou.net Feb. 27, 2015

Feb. 27, 2015

results for 2eb99070a38f on branch "default" -------------------------------------------- test_asyncio leaked [0, 3, 0] memory blocks, sum=3 test_collections leaked [-2, -4, 0] references, sum=-6 test_collections leaked [-1, -2, 0] memory blocks, sum=-3 test_functools leaked [0, 0, 3] memory blocks, sum=3 Command line was: ['./python', '-m', 'test.regrtest', '-uall', '-R', '3:3:/home/antoine/cpython/refleaks/reflogqNNRjK', '-x']

1 0

peps: PEP 478: 4 PEP have been accepted for python 3.5
by victor.stinner Feb. 27, 2015

Feb. 27, 2015

https://hg.python.org/peps/rev/7ca0d878a773 changeset: 5712:7ca0d878a773 user: Victor Stinner <victor.stinner(a)gmail.com> date: Fri Feb 27 10:18:27 2015 +0100 summary: PEP 478: 4 PEP have been accepted for python 3.5 files: pep-0478.txt | 7 ++++--- 1 files changed, 4 insertions(+), 3 deletions(-) diff --git a/pep-0478.txt b/pep-0478.txt --- a/pep-0478.txt +++ b/pep-0478.txt @@ -62,18 +62,19 @@ Accepted PEPs: +* PEP 441, improved Python zip application … [View More]

1 0

cpython (merge 3.4 -> default): Merge with 3.4
by zach.ware Feb. 27, 2015

Feb. 27, 2015

https://hg.python.org/cpython/rev/344d57c521b9 changeset: 94770:344d57c521b9 parent: 94768:430cab0c5cbf parent: 94769:d0e15d9cdd4b user: Zachary Ware <zachary.ware(a)gmail.com> date: Fri Feb 27 01:40:41 2015 -0600 summary: Merge with 3.4 files: Doc/library/stdtypes.rst | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/Doc/library/stdtypes.rst b/Doc/library/stdtypes.rst --- a/Doc/library/stdtypes.rst +++ b/Doc/library/stdtypes.rst @@ … [View More]

1 0