[Python-Dev] cpython (2.7): - Issue #17086: Backport the patches from the 3.3 branch to cross-build
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
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
> - 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.
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.
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
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