Mailman 3 January 2012 - Python-Dev

Hashing proposal: change only string-only dicts
by "Martin v. Löwis" Jan. 20, 2012

Jan. 20, 2012

I'd like to propose a different approach to seeding the string hashes: only do so for dictionaries involving only strings, and leave the tp_hash slot of strings unchanged. Each string would get two hashes: the "public" hash, which is constant across runs and bugfix releases, and the dict-hash, which is only used by the dictionary implementation, and only if all keys to the dict are strings. In order to allow caching of the hash, all dicts should use the same hash (if caching wasn't necessary, … [View More]

10 17

negative ref count on windows debug version
by Dr.-Ing. Ingo D. Rullhusen Jan. 20, 2012

Jan. 20, 2012

Hello, using loc = PyDict_New(); Py_XDECREF(loc); or PyObject *src = Py_CompileString( code.toStdString().c_str(), "<console>", Py_single_input ); Py_XDECREF(src); results in a "object at blahblah has negative ref count -1" error on windows visual studio in debug mode. And yes, python is compiled and linked in debug mode also. The release version seems to work. This happens in version 2.6.7 and 2.7.2. Any hints? Thanks Ingo

2 1

PEP 407: New release cycle and introducing long-term support versions
by Antoine Pitrou Jan. 20, 2012

Jan. 20, 2012

Hello, We would like to propose the following PEP to change (C)Python's release cycle. Discussion is welcome, especially from people involved in the release process, and maintainers from third-party distributions of Python. Regards Antoine. PEP: 407 Title: New release cycle and introducing long-term support versions Version: $Revision$ Last-Modified: $Date$ Author: Antoine Pitrou <solipsis(a)pitrou.net>, Georg Brandl <georg(a)python.org>, Barry Warsaw <barry(… [View More]a)python.org> Status: Draft Type: Process Content-Type: text/x-rst Created: 2012-01-12 Post-History: Resolution: TBD Abstract ======== Finding a release cycle for an open-source project is a delicate exercise in managing mutually contradicting constraints: developer manpower, availability of release management volunteers, ease of maintenance for users and third-party packagers, quick availability of new features (and behavioural changes), availability of bug fixes without pulling in new features or behavioural changes. The current release cycle errs on the conservative side. It is adequate for people who value stability over reactivity. This PEP is an attempt to keep the stability that has become a Python trademark, while offering a more fluid release of features, by introducing the notion of long-term support versions. Scope ===== This PEP doesn't try to change the maintenance period or release scheme for the 2.7 branch. Only 3.x versions are considered. Proposal ======== Under the proposed scheme, there would be two kinds of feature versions (sometimes dubbed "minor versions", for example 3.2 or 3.3): normal feature versions and long-term support (LTS) versions. Normal feature versions would get either zero or at most one bugfix release; the latter only if needed to fix critical issues. Security fix handling for these branches needs to be decided. LTS versions would get regular bugfix releases until the next LTS version is out. They then would go into security fixes mode, up to a termination date at the release manager's discretion. Periodicity ----------- A new feature version would be released every X months. We tentatively propose X = 6 months. LTS versions would be one out of N feature versions. We tentatively propose N = 4. With these figures, a new LTS version would be out every 24 months, and remain supported until the next LTS version 24 months later. This is mildly similar to today's 18 months bugfix cycle for every feature version. Pre-release versions -------------------- More frequent feature releases imply a smaller number of disruptive changes per release. Therefore, the number of pre-release builds (alphas and betas) can be brought down considerably. Two alpha builds and a single beta build would probably be enough in the regular case. The number of release candidates depends, as usual, on the number of last-minute fixes before final release. Effects ======= Effect on development cycle --------------------------- More feature releases might mean more stress on the development and release management teams. This is quantitatively alleviated by the smaller number of pre-release versions; and qualitatively by the lesser amount of disruptive changes (meaning less potential for breakage). The shorter feature freeze period (after the first beta build until the final release) is easier to accept. The rush for adding features just before feature freeze should also be much smaller. Effect on bugfix cycle ---------------------- The effect on fixing bugs should be minimal with the proposed figures. The same number of branches would be simultaneously open for regular maintenance (two until 2.x is terminated, then one). Effect on workflow ------------------ The workflow for new features would be the same: developers would only commit them on the ``default`` branch. The workflow for bug fixes would be slightly updated: developers would commit bug fixes to the current LTS branch (for example ``3.3``) and then merge them into ``default``. If some critical fixes are needed to a non-LTS version, they can be grafted from the current LTS branch to the non-LTS branch, just like fixes are ported from 3.x to 2.7 today. Effect on the community ----------------------- People who value stability can just synchronize on the LTS releases which, with the proposed figures, would give a similar support cycle (both in duration and in stability). People who value reactivity and access to new features (without taking the risk to install alpha versions or Mercurial snapshots) would get much more value from the new release cycle than currently. People who want to contribute new features or improvements would be more motivated to do so, knowing that their contributions will be more quickly available to normal users. Also, a smaller feature freeze period makes it less cumbersome to interact with contributors of features. Discussion ========== These are open issues that should be worked out during discussion: * Decide on X (months between feature releases) and N (feature releases per LTS release) as defined above. * For given values of X and N, is the no-bugfix-releases policy for non-LTS versions feasible? * Restrict new syntax and similar changes (i.e. everything that was prohibited by PEP 3003) to LTS versions? * What is the effect on packagers such as Linux distributions? * How will release version numbers or other identifying and marketing material make it clear to users which versions are normal feature releases and which are LTS releases? How do we manage user expectations? A community poll or survey to collect opinions from the greater Python community would be valuable before making a final decision. Copyright ========= This document has been placed in the public domain. .. Local Variables: mode: indented-text indent-tabs-mode: nil sentence-end-double-space: t fill-column: 70 coding: utf-8 End: [View Less]

23 58

Summary of Python tracker Issues
by Python tracker Jan. 20, 2012

Jan. 20, 2012

ACTIVITY SUMMARY (2012-01-13 - 2012-01-20) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open 3209 ( -1) closed 22405 (+53) total 25614 (+52) Open issues with patches: 1376 Issues opened (37) ================== #13411: Hashable memoryviews http://bugs.python.org/issue13411 reopened by skrah #13782: xml.etree.ElementTree: Element.append doesn't type-… [View More]

1 0

Re: [Python-Dev] [Python-checkins] cpython (3.1): Closes #13807: Now checks for sys.stderr being there before writing to it.
by Meador Inge Jan. 20, 2012

Jan. 20, 2012

On Fri, Jan 20, 2012 at 5:32 AM, vinay.sajip <python-checkins(a)python.org> wrote: > http://hg.python.org/cpython/rev/73dad4940b88 > changeset: 74538:73dad4940b88 > branch: 3.1 I thought that the 3.1 branch is in security mode? Is this a security related fix? >From my brief scan of the changeset, it doesn't seem to be. > parent: 74253:fb5707168351 > user: Vinay Sajip <vinay_sajip(a)yahoo.co.… [View More]

1 0

Writable __doc__
by Ethan Furman Jan. 19, 2012

Jan. 19, 2012

Is there a reason why normal classes can't have their __doc__ strings rewritten? Creating a do-nothing metaclass seems like overkill for such a simple operation. Python 3.2 ... on win32 --> class Test(): ... __doc__ = 'am I permanent?' ... --> Test.__doc__ 'am I permanent?' --> Test.__doc__ = 'yes' Traceback (most recent call last): File "<stdin>", line 1, in <module> AttributeError: attribute '__doc__' of 'type' objects is not writable --> type(Test) <class '… [View More]

11 16

Re: [Python-Dev] [Python-checkins] cpython (2.7): Issue #13605: add documentation for nargs=argparse.REMAINDER
by Sandro Tosi Jan. 19, 2012

Jan. 19, 2012

On Thu, Jan 19, 2012 at 22:07, Terry Reedy <tjreedy(a)udel.edu> wrote: > typo ... > lits .> list yep, i've already fixed it committing a more useful example too -- Sandro Tosi (aka morph, morpheus, matrixhasu) My website: http://matrixhasu.altervista.org/ Me at Debian: http://wiki.debian.org/SandroTosi

1 0

Re: [Python-Dev] [Python-checkins] cpython (2.7): Issue #13605: add documentation for nargs=argparse.REMAINDER
by Nadeem Vawda Jan. 19, 2012

Jan. 19, 2012

On Thu, Jan 19, 2012 at 11:03 PM, sandro.tosi <python-checkins(a)python.org> wrote: > + are gathered into a lits. This is commonly useful for command line s/lits/list ?

2 1

Re: [Python-Dev] [Python-checkins] cpython: add str.casefold() (closes #13752)
by Éric Araujo Jan. 19, 2012

Jan. 19, 2012

Hi, > changeset: d4669f43d05f > user: Benjamin Peterson <benjamin(a)python.org> > date: Sat Jan 14 13:23:30 2012 -0500 > summary: > add str.casefold() (closes #13752) > diff --git a/Doc/library/stdtypes.rst b/Doc/library/stdtypes.rst > --- a/Doc/library/stdtypes.rst > +++ b/Doc/library/stdtypes.rst > @@ -1002,6 +1002,14 @@ > rest lowercased. > > > +.. method:: str.casefold() > + > + Return a casefolded copy of the … [View More]

1 1

Re: [Python-Dev] [Python-checkins] Daily reference leaks (12de1ad1cee8): sum=6024
by Nick Coghlan Jan. 19, 2012

Jan. 19, 2012

On Wed, Jan 18, 2012 at 2:31 PM, <solipsis(a)pitrou.net> wrote: > results for 12de1ad1cee8 on branch "default" > -------------------------------------------- > > test_capi leaked [2008, 2008, 2008] references, sum=6024 Yikes, you weren't kidding about that new subinterpreter code execution test upsetting the refleak detection... Cheers, Nick. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia

4 7