On 2/19/2013 9:48 PM, Todd Rovito wrote:
Please see http://www.python.org/dev/peps/pep-0434/ for the complete PEP. The idea for the PEP was generated because a right click menu was added to IDLE in Python 2.7 this started a debate about bug fix VS enhancement see the PEP references for more information. IDLE has many patches that already exist but are difficult to get committed. This PEP is designed to make it easier to bring IDLE up to speed with modern GUI standards. The PEP is not perfect some issues that need to be solved:
In my view, the PEP is definitely about allowing minor enhancements to existing features in bugfix releases. It is maybe about backporting new features such as would require a new entry on the menus. The right-click menu does not fit either category but it is more like the latter. In any case, I think it is an innocuous addition and should be allowed if a committer wants to do the backport. I do not think the PEP should be a blank check to backport currently hypothetical major revisions such a themed widgets or tabbed windows. If and when such a thing is tested and ready to be put into the 'next' version, the possibility of backporting it should be a separate discussion.
-How do we test IDLE patches to make sure they are high quality?
This is a separate issue from the PEP. Those of us who have and are working on IDLE issues are aware of the need to test on Windows, Linux, and Mac, and to test 2.7 separately from 3.x. There is a tracker issue for improving IDLE tests.
-Does it make sense to separate IDLE from the stdlib for Python 3.4?
Not to me.
I understand the batteries included argument, but if IDLE development is going to continue to proceed at a more accelerated pace than Python, it might make sense to separate it out into its own project or a sub-project.
We typically release bugfixes about every 6-9 months and I think that is often enough to release changes. The subject of the PEP is what should go into those releases. -- Terry Jan Reedy