Python 3 is killing Python

Terry Reedy tjreedy at
Fri Jul 18 02:13:44 CEST 2014

On 7/17/2014 2:15 PM, Rick Johnson wrote:
a partial disinformation rant again Idle
that repeats things said before, more than once.

In general, your rants seem to serve the social purpose of providing 
cover to other people to join in loose, off-topic discussions. In this 
one, you align yourself with the 'private boys club' idle haters you 
profess to disdain.

Some facts. Idlelib has about 60 modules. The tracker has, as I write, 
133 open issues (behavior and enhancements, with the boundary sometimes 
fuzzy) marked Component: Idle. That is about two issues per module. It 
is definitely less than 1 bug per 100 lines. There is only 1 bug, 
Windows-specific, that routinely gets in my way.

The stdlib has, I believe, less than 1000 modules. There are right now 
4545 open issues, or at least 4, maybe more, per module. Anyone who 
calls Idle (or anything else) 'buggy' and 'embarassing' should do some 
research and say 'compared to what' and 'by what standard'.

Last January, I discovered that tokenize.untokenize had about 5 bugs in 
about 25 lines of code. The new mode was hardly usable. I think *that* 
could be called 'embarassing' -- compared to the rest of the stdlib and 
by the standard of being basically usable. I fixed all but 1 of the 
implementation bugs.

More facts. Since 2.7 was released in July 2010, there have been 94 
issues with improvements recorded in idlelib/news.txt (extracted from 
the 2.7 news/changelog).  (Some issues have multiple patches, and some 
patches no recorded issue, but we can stick with the recorded issue 
count.)  Has the patch rate gone down or up?  Over half (46) of the 
issue patches are recorded in the last 15 months out of 48, less than a 
third, after the release of 2.7.5 on 2013 April 4. The reason for the 
uptick is PEP 434, which ended the blockage of Idle patches by useless 
debates over 'behavior' versus 'enhancement' and backport or not'.  It 
also ended (most of) the Idle hate rants on pydev.

> Sadly, all of my calls to improve IDLE have been meet with
> rebukes about me "whining".

Each of the 133 issues on the tracker is a specific, usually actionable, 
'call' to improve Idle. They are gradually being attended to. Generic 
'calls for improvement' on this list are useless.

 > The "powers that be"

When it comes to Idle, that means me as much as anyone.

> would wise to *UTILIZE* and *ENCOURAGE* my participation  <blah blah ...>

Still more facts ;-). About three (four?) years ago, you posted a 
similar rant. Being wise, I encouraged your participation and utilized 
the patch you anonymously posted on the tracker (to maintain your 
Ranting Rick pose) in one of my first commits. I invite you to resume 
your participation, either anonymously or openly.  As before, you can 
email me privately to discuss what would best suite you and also be helpful.

I will mention that one barrier to improving Idle code, beyond making 
small local fixes, is the need for automated tests before refactoring. I 
started a unittest suite in May 2013 with the help of GSOC (Google 
Summer of Code) students. In May 2014, this year's student and I 
collected together and improved the human-run tests.

Terry Jan Reedy

More information about the Python-list mailing list