[Python-ideas] Updated PEP 434: IDLE Enhancement Exception

Terry Reedy tjreedy at udel.edu
Thu Mar 7 02:22:55 CET 2013


On 3/5/2013 7:15 PM, Terry Reedy wrote:
> I rewrote the PEP to better focus on the specific proposal and
> motivation. I also refined the formatting and added something about
> backwards compatibility with extensions.

Below are my answers the issues raise by Nick on pydev in response to 
Todd's initial version, posted there before moving to python-ideas.

 > be specific about which parts of the code base are covered by the 
exception

I added this to the summary -- everything in idlelib/*.

 > The rationale needs to be fleshed out a bit more along the lines of
"IDLE is primarily used as an application that ships with Python,
rather than as a library module used to build Python applications,
that's why it is OK for a different standard to apply".

Todd added something like this and I reworded to say much the same thing.

 > Mentioning the point about Linux distros splitting it out into a 
separate package would also be useful.

I know nothing about Linux distros and so that is not a motivating point 
for me. But if given a sentence that you (Nick) consider valid, and a 
suggestion of where to put it, I will certainly add it.

 > no need for extensive cross-OS testing prior to commit, that's a key
part of the role of the buildbots

I removed much of the discussion about testing as the PEP does not 
propose to change the rules about test before commit. I already opened 
an issue about improving automatic testing.
http://bugs.python.org/issue15392

 > [sparse test suite] Perhaps something for the PEP to elaborate on 
before we declare open season on Idle improvements in bug fix releases.

The alternative to automatic testing is testing by hand rather than no 
testing. I mentioned that backporting is extra work for developers, that 
this extra work might mean not backporting, and that both are true 
regardless of how an improvement might be classified.

IDLE's current tests are all within /idlelib, just as tkinter tests live 
within /tkinter. If this PEP is approved, new tests can be backported 
without controversy. My understanding is that that is not true for 
coverage tests for other modules. Backporting a new test_idle.py in 
Lib/test, similar to test_tkinter.py, is not covered by this PEP.

-- 
Terry Jan Reedy




More information about the Python-ideas mailing list