Should non-security 2.7 bugs be fixed?

[Jason Swails]

I am a little late to the party, but I feel that I have something to
contribute to this discussion.  Apologies for the top-post, but it's really
in response to any particular question; more of a "this is my story with
Python 2.7".  I still use primarily Python 2.7, although I write code using
six to support both Py2 and 3 in the same code base and I'm slowly making
the transition.

I have written Python code for primarily Linux machines only since 2008,
and until the last year or two, exclusively for Python 2.  In my brief,
early forays into Python 3, I experienced mostly discomfort.  Discovering
2to3 alleviated some of that. But my general lack of need for anything
beyond ASCII meant that when my abstracted file reading/writing routines
started returning/requiring a mishmash of bytes and str depending on what
kind of file was opened sent me into a TypeError/AttributeError rabbithole
and made me give up.

But Python 2 continued to get developed (eventually culminating in Python
2.7 and its continual improvements), and many good features of Python 3
found its way into Python 2.7 for awhile.  As I got better with Python 2.7,
and finally abandoned Python <2.7, I revisited Python 3 support through the
six module and found that it was really not too bad maintaining a single
code base for both Python 2.7 and Python 3+.  While I was working on that,
though, I still had Python 2.7 to rely on as a safety net.  Basically,
Python 2.7 was my gateway into Python 3.  Where it was more similar to
Python 3, the transition was easier (modules like urllib and website
processing as well as Tkinter coding are some of my more difficult tasks,
since I have to constantly look up where stuff has moved and figure out how
compatible they are between versions). I have also since discovered
TextIOWrapper and come to understand the nature of the bytes/str split and
when to expect which, so that's no longer a problem (even though I still
never need Unicode).

And the more I use six, the more I find that I'm discarding Python 2
baggage (like range and zip in exchange for xrange and izip) and using the
Python 3 replacements through six or __future__ (absolute imports, print
function, division, ...).  And gems like OrderedDict being made available
to Python 2.7 did a lot to convince me to shed my allegiance to Python
<=2.6, getting me even closer to Python 3.

Where I used to see the Py3 overhaul of I/O as an incomprehensible mess
(because it broke all my code!), It now appears as an elegant solution and
I find myself having to patch (fortunately only a few) deficiencies in
Python 2 that simply don't exist in Python 3's superior design.  For
example:

# Works in Python 3, not in Python 2
from six.moves.urllib.request import urlopen
import bz2
import gzip
from io import TextIOWrapper

TextIOWrapper(bz2.BZ2File(urlopen('
http://www.somewebsite.com/path/to/file.bz2')))
TextIOWrapper(gzip.GzipFile(fileobj=urlopen('
http://www.somewebsite.com/path/to/file.gz')))

So for Python 2, my file handling routine has to download the entire
contents to a BytesIO and feed *that* to bz2.decompress or gzip.GzipFile,
which can be a bottleneck if I only want to inspect the headers of many
large files (which I sometimes do).  But the workaround exists and my code
can be written to support both Python 2 and Python 3 without much hassle.
If I run that code under Python 3, I get a huge performance boost in some
corner cases thanks to the improved underlying design.

Python 3 is the future, and thanks to how *good* Python 2.7 is, I am ready
to make that leap and shed some extra code baggage when the popular
versions of the popular Linux distros make the move to a default system
Python 3 (and they will... someday).

I know my experiences don't hold true for everybody, but I also don't think
they are uncommon (I know several colleagues that share many aspects of
them).  And for me, the *better* Python 2.7 becomes, and the longer it's
kept around, the easier (and more fun!) it makes my transition to Python
3.  So for me at least, arguments like "don't make Python 2.7 too good or
people won't switch" are not only wrong, but in actuality
counter-productive.

Apologies for the novel,
Jason

On Sat, Jul 18, 2015 at 7:36 PM, Terry Reedy <tjreedy at udel.edu> wrote:

> I asked the following as an off-topic aside in a reply on another thread.
> I got one response which presented a point I had not considered.  I would
> like more viewpoints from 2.7 users.
>
> Background: each x.y.0 release normally gets up to 2 years of bugfixes,
> until x.(y+1).0 is released.  For 2.7, released summer 2010, the bugfix
> period was initially extended to 5 years, ending about now.  At the spring
> pycon last year, the period was extended to 10 years, with an emphasis on
> security and build fixed.  My general question is what other fixes should
> be made?  Some specific forms of this question are the following.
>
> If the vast majority of Python programmers are focused on 2.7, why are
> volunteers to help fix 2.7 bugs so scarce?
>
> 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
>
> --
> https://mail.python.org/mailman/listinfo/python-list
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-list/attachments/20150723/00d41056/attachment.html>