[Python-Dev] cpython (2.7): - Issue #17086: Backport the patches from the 3.3 branch to cross-build (original) (raw)

Terry Reedy tjreedy at udel.edu
Thu Feb 7 01:19:50 CET 2013

On 2/6/2013 8:16 AM, Matthias Klose wrote:

Am 05.02.2013 07:13, schrieb Terry Reedy:

On 2/4/2013 3:04 PM, Matthias Klose wrote:

- there were way too may regressions checked in on at least the 2.7 branch.

I think you are using 'regression' too freely. But that aside, I think you are pointing to a legitimate issue, in the first and maybe second example of how to handle 2.7.

Regressions? That normally means adding a bug as part of a patch, especially one that was previously fixed. We continually add tests to try to prevent that. What period of time do you mean 'were' to refer to? - http://bugs.python.org/issue9374

From what I read (but it was a long discussion), this patch fixed behavior that was agreed to be a bug. The disagreement was whether the bug was clear or obscure. Since the bug was long-standing, and since much code had accommodated to the bug, and even depended on it, the bugfix broke more code than usual. This is not a regression, but is a concern, and if I understand correctly, the fix was removed or revised for existing versions.

- http://bugs.python.org/issue15906

I did not understand the issue, except to note that it affected all versions, involved apparent ambiguity in the doc, and was caught by ubuntu testing.

- http://bugs.python.org/issue16012

This reported a clear regression, on all versions, not just 2.7, that was caught before release. As the person responsible for the regression said "Too bad it [the regressed behavior] wasn't tested for :(". We still need more patches to improve test coverage.

- http://bugs.python.org/issue10182

This fixed an all-versions bug in _sre. The initial patch was fine for 3.x but not sufficiently adjusted for 2.7. Py_BuildValue needed to be replaced in certain places with PyInt_FromSsize_t rather than PyLong_FromSsize_t to maintain the external API. This was not caught because by the stdlib test but was by a third party who tests their package with tip. Yay for them. The process worked.

- http://bugs.python.org/issue16828

Again, an all-versions issue, not 2.7 specific. http://bugs.python.org/issue14398 disabled compression of '' in the process of enabling compression of

4GB strings. Not a bad tradeoff, really, but not best. Again, this was not caught initially because there was no stdlib test for ''. But there was in a 2.7 ubuntu package.

not a complete list, all these are past the 2.7.3 release.

In only 1 of the 5 was there a 2.7-specific regression. I am not sure what specific change you would like. In the last three examples, would you want 2.7 left with the bug?

Is it just our vcs merge model that we first have to check in on the branches, and then merge to the trunk?

Mercurial works best if merges are done in the forward direction. However, this is not relevant to 2.7 patches as they are pushed to tip but not merged. The repository is a two-headed monster ;=). so it should be possible to delay patches for 2.7 until they don't show issues in 3.2 or 3.3.

Yes, however

  1. Later may mean never.
  2. If the regression is 2.7 specific, as with #10182, then not showing an issue for 3.x is irrelevant.
  3. If the regression is general, then at present, the 2.7 regression is the most likely to be caught by external testing (mostly by unbuntu). That says to me that bug fixes for 2.7 should go into tip along with the others. I could even argue that the 2.7 fix should go in first.
  4. If bugfixes are not applied to 2.7, that increases the distance between 2.7 and 3.x and possibly increases the difficulty of writing 2&3 code.

If we do leave a fixed-in-3.x bug in 2.7, then perhaps, if it is possible to detect that the bug is being depended upon, there should be a deprecation warning in the code.

-- Terry Jan Reedy

More information about the Python-Dev mailing list