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
IDLE-dev@python.org
https://mail.python.org/mailman/listinfo/idle-dev

Reply via email to