Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #94166 > unrolled thread

Re: Should non-security 2.7 bugs be fixed?

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Should non-security 2.7 bugs be fixed? Terry Reedy <tjreedy@udel.edu> - 2015-07-19 17:27 -0400

#94166 — Re: Should non-security 2.7 bugs be fixed?

On 7/19/2015 5:27 AM, Laura Creighton wrote:
> In a message of Sat, 18 Jul 2015 19:36:33 -0400, Terry Reedy writes:
>> If the vast majority of Python programmers are focused on 2.7, why are
>> volunteers to help fix 2.7 bugs so scarce?
>
> Because volunteers to fix any bugs are scarce?  Because most people really
> only think of bug fixing when they have one, and when they get that
> one fixed they drop back into thinking that everything is perfect?
>
>> Does they all consider it perfect (or sufficient) as is?
>>
>> Should the core developers who do not personally use 2.7 stop
>> backporting, because no one cares if they do?
>>
>> --
>> Terry Jan Reedy
>
> In the tiny corner of industrial automation where I do a lot of work,
> nobody is using 3.0.  It is not clear that this is ever going to change.
> It would have to be driven by 'lack of people who know 2.x syntax'
> or something like that. Not 'third party library compatibility' because
> we really don't use them all that much.
>
> In this corner of the world, the favourite language for developing in
> is C (because we work close to hardware) and one of the things we like
> about it, a whole lot, is that the language never changes out from
> under you.  So there is great hope among industrial users of Python
> that we can get a hold of a 'never going to change any more' version
> of Python, and then code in that 'forever' knowing that a code change
> isn't going to come along and break all our stuff.

Any version of Python too old even for security patches would qualify. 
Of course, in a chaotic environment, static code may mean unstatic 
behavior.  Changing internet attacks and changing build environments are 
the prime reason for extending 2.7 maintenance.

> Bug fixes aren't supposed to do this, of course, in the same way that
> backporting of features do, but every so often something that was
> introduced to fix bug X ends up breaking something else Y.  If the
> consequences of a bug can be 10s of thousands of Euros lost, you
> can see the appeal of 'this isn't going to happen any more'.
>
> While nobody likes to get bit by bugs, there is some sort of fuzzy
> belief out there that the bugs fixes that have gone into 2.7 are
> more about things that we would never run into, and thus we get the
> risk of change without the benefit of the bugfix.  This belief isn't
> one that people substantiate -- it is 'just a feeling'.
>
> So from this corner of the world, which admittedly is a very small corner,
> yes, the news is 'Life is good.  Please leave us alone.'  This is in
> large part, I think, due to the belief that 'if things aren't breaking,
> things are perfect' which is completely untrue, but that's the way
> people are thinking.

The extended extended maintenance for 2.7 (from now to 2020) is 
primarily for security and build fixes.  I am beginning to think that 
the ambiguity of 'secondarily for other fixes, on a case-by-case basis, 
as determined by the whim of individual core developers' is a disservice 
to most users as well as most core developers.

-- 
Terry Jan Reedy

[toc] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web