Should non-security 2.7 bugs be fixed?

Terry Reedy tjreedy at
Mon Jul 20 08:25:25 CEST 2015

On 7/19/2015 9:20 PM, Devin Jeanpierre wrote:

> Search your logs for
> I was most frustrated by the first case --
 > the patch was (informally) rejected

By 'the patch', I presume you mean current-frames-cleanup.patch
by Stefan Ring, who said it "is certainly not the most complete 
solution, but it solves my problem.". It was reviewed a month later by a 
core dev, who said it had two defects.  Do you expect us to apply 
defective patches?

> in favor of the "right" fix,

"right" is your word. Natali simply uploaded an alternate patch that did 
not have the defects cited.  It went through 4 versions, two by Pitrou, 
before the commit and close 2 months later, with the comment "Hopefully 
there aren't any applications relying on the previous behaviour."

 >and the "right" fix was (informally) rejected because it changed behavior,

The bugfix was rejected *for both 2.7 and 3.3* in msg186011.  The 
rejection therefore does not indicate animus against 2.7 versus 3.x. The 
reason is that it did more than just fix the bug. When this is the case, 
we only apply to the upcoming release.  If we broke working code as a 
side-effect, as opposed to a direct effect, of a bugfix, many people 
would be frustrated. See some of the other comments in this thread.

Two years later, last May, you proposed and uploaded a patch with what 
looks to be a new and different approach.  It has been ignored.  In the 
absence of a core dev focused on 2.7, I expect that this will continue. 
Too bad you did not upload it in Feb 2013, before the review and fix 

 > and

Another fairly obscure issue for most of us. Five years ago, this was 
turned into a doc issue, but no patch was ever submitted for either 2.x 
or 3.x.  Again, no particular prejudice against 2.x.

In May, you posted a bugfix which so far has been ignored.  Not too 
surprising.  I submitted a ping and updated the versions.  If anyone 
responds, you might be asked for a patch against 3.4 or 3.5.

Terry Jan Reedy

More information about the Python-list mailing list