<div dir="ltr"><div class="gmail_default" style="color:#000000">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.</div><div class="gmail_default" style="color:#000000"><br></div><div class="gmail_default" style="color:#000000">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.</div><div class="gmail_default" style="color:#000000"><br></div><div class="gmail_default" style="color:#000000">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).</div><div class="gmail_default" style="color:#000000"><br></div><div class="gmail_default" style="color:#000000">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.</div><div class="gmail_default" style="color:#000000"><br></div><div class="gmail_default" style="color:#000000">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:</div><div class="gmail_default" style="color:#000000"><br></div><div class="gmail_default" style="color:#000000"># Works in Python 3, not in Python 2</div><div class="gmail_default" style="color:#000000">from six.moves.urllib.request import urlopen</div><div class="gmail_default" style="color:#000000">import bz2</div><div class="gmail_default" style="color:#000000">import gzip</div><div class="gmail_default" style="color:#000000">from io import TextIOWrapper</div><div class="gmail_default" style="color:#000000"><br></div><div class="gmail_default" style="color:#000000">TextIOWrapper(bz2.BZ2File(urlopen('<a href="http://www.somewebsite.com/path/to/file.bz2')">http://www.somewebsite.com/path/to/file.bz2')</a>))</div><div class="gmail_default" style="color:#000000">TextIOWrapper(gzip.GzipFile(fileobj=urlopen('<a href="http://www.somewebsite.com/path/to/file.gz')">http://www.somewebsite.com/path/to/file.gz')</a>))</div><div class="gmail_default" style="color:#000000"><br></div><div class="gmail_default" style="color:#000000">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.</div><div class="gmail_default" style="color:#000000"><br></div><div class="gmail_default" style="color:#000000">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).</div><div class="gmail_default" style="color:#000000"><br></div><div class="gmail_default" style="color:#000000">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.</div><div class="gmail_default" style="color:#000000"><br></div><div class="gmail_default" style="color:#000000">Apologies for the novel,</div><div class="gmail_default" style="color:#000000">Jason</div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jul 18, 2015 at 7:36 PM, Terry Reedy <span dir="ltr"><<a href="mailto:tjreedy@udel.edu" target="_blank">tjreedy@udel.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br>
<br>
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.<br>
<br>
If the vast majority of Python programmers are focused on 2.7, why are volunteers to help fix 2.7 bugs so scarce?<br>
<br>
Does they all consider it perfect (or sufficient) as is?<br>
<br>
Should the core developers who do not personally use 2.7 stop backporting, because no one cares if they do?<span class="HOEnZb"><font color="#888888"><br>
<br>
-- <br>
Terry Jan Reedy<br>
<br>
-- <br>
<a href="https://mail.python.org/mailman/listinfo/python-list" rel="noreferrer" target="_blank">https://mail.python.org/mailman/listinfo/python-list</a></font></span></blockquote></div>
</div></div>