Some researchers found an error in the logic of merge_collapse, explained here, and with corrected code shown in section 3.2:

http://envisage-project.eu/proving-android-java-and-python-sorting-algorithm-is-broken-and-how-to-fix-it/

This affects all current versions of Python.  However, I marked the priority "low" because, as the article also notes, there's currently no machine in existence with enough memory to hold an array large enough for a contrived input to trigger an overflow of the pending-runs stack. 

It should be fixed anyway, and their suggested fix looks good to me.

New changeset 325aec842e3e by Benjamin Peterson in branch '2.7':
fix merge_collapse to actually maintain the invariant it purports to (closes #23515)
https://hg.python.org/cpython/rev/325aec842e3e

New changeset 620cb13008b7 by Benjamin Peterson in branch '3.4':
fix merge_collapse to actually maintain the invariant it purports to (closes #23515)
https://hg.python.org/cpython/rev/620cb13008b7

New changeset be5ddc8b6a88 by Benjamin Peterson in branch 'default':
merge 3.4 (#23515)
https://hg.python.org/cpython/rev/be5ddc8b6a88

@Benjamin, bless you for changing their "n-1 > 0" to "n > 1", and for adding parentheses to make the intended grouping obvious instead of a puzzle, and for swapping the addends on the RHS of the new test.  Thank you - perfect :-)

How additional test affects performance? May be just increase MAX_MERGE_PENDING?

Since it's impossible to trigger the error on any current machine anyway (no machine has enough memory), increasing the size of the stack would be absurd.  If you read the paper, they note that this is what the Java folks first did (they changed this part of timsort in a way that _did_ make it possible to provoke the stack overflow on current hardware).  And they got it wrong, not increasing it enough.  Without the _intended_ invariant, it's difficult to figure out how much is enough.

It's not worth measuring performance.  If there are a total of R runs in the input array, a total of R-1 merges will be performed (with or without the change).  As explained in listsort.txt, per-merge overheads don't matter at all unless they're outrageous, because there are at most ceiling(len(array)/32) runs.  So the total number of merges is a small fraction of the number of array elements (call that `N`), in an N*log(N) process.  Adding a few native C integer comparisons per merge (as the change essentially does) is trivial.

It may be possible to contrive inputs which run significantly slower (or faster!) with the change, because the order in which runs are merged may change.  But then you'd just be chasing patterns of HW and OS layers-of-caching behavior specific to the box the test is running on.

Thank you for your explanation Tim.

I sent a note to the lead author Stijn de Gouw and mentioned that the repository has moved from svn to hg.python.org.

This change may be moot, but I think it worth our effort to keep our code as clean as possible and to encourage automated code checks, as we have by responding to issues raised by Coverity.  Maybe next time, this group will find a bug that does matter now.

Thanks, Terry!  Absolutely agreed:  a logical error is an error, and will bite us eventually, regardless of whether it does so today.  I'm very glad the researchers went to all the trouble to analyze this one :-)