[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