Freezing 2.7 and moving on

Terry Reedy <[email protected]> Sun, 17 Jan 2016 03:19:29 -0500
Newsgroups gmane.comp.python.idle
Message-ID <[email protected]>
The new releases are out, the holidays over, I can now build 3.5/6, and 
I have restarted working on IDLE.  I have decided that other people were 
right; backporting ttk use and other big changes to 2.7 was a foolish 
idea.  This will mean mostly freezing IDLE for 2.7.

For myself, I will only backport easily backported fixes to IDLE startup 
failures.  Example: IDLE not starting because of duplicate names (such 
as 'string.py' in their directory and /Lib.  Only a few lines should be 
needed to fix this, and the backport will currently be trivial.

A summary of my reasons:

1. People still using 2.7 are by definition conservative and may not 
want a major change.  The extended extended maintenance period for 2.7, 
already begun, was intended mainly for security and build problems. 
Judging from IDLE questions on Stackoverflow, the number of courses 
using IDLE with 2.7 may be shrinking.

2. I have no person interest in 2.7 and remembering its peculiarities; 
the burden of remembering differences is growing; for 3.5, I want to 
write in 3.5 and be able to use any feature available.  For example, if 
async can be used with tkinter, that might solve some IDLE problems.

3. As some as some patches are not backported, the burden of backporting 
most other patches will increase.  Not backporting to 2.7 also means not 
backporting to the legacy 2.7-like code included with 3.5.

4. Backports need separate testing.  Testing is already inadequate. 
Even seemingly 'safe' patches can cause regresssions.  Example: 
rewriting README.txt. https://bugs.python.org/issue25224.
I did not ask Mark to test my final patch on Linux/MAC either before or 
after applying.  However, the text editor I used (Notepad++ I thing, but 
not sure), converted ascii ' to non-ascii ’ with latin-1 encoding.  The 
result is that on *some* systems displaying README.txt in About IDLE 
fails in any of the new releases.

5. While nearly the most innocuous regression possible, the shock 
convinced me that the only way to successfully revamp IDLE is to focus 
on revised and new code for 3.5 and 3.6.

Another possible factor is that the main IDLE repository will move from 
hg on a PSF server to git on Github.  I don't know what the impact of 
this will be.

-- 
Terry Jan Reedy


_______________________________________________
IDLE-dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/idle-dev