[Python-Dev] Cut/Copy/Paste items in IDLE right click context menu

Nick Coghlan ncoghlan at gmail.com
Fri Nov 2 16:16:12 CET 2012


On Sat, Nov 3, 2012 at 12:46 AM, Andrew Svetlov
<andrew.svetlov at gmail.com> wrote:
> Hi. There are issue for subject: http://bugs.python.org/issue1207589
> It has patches, implemented well and committed.
> I've pushed it to versions 2.7, 3.2, 3.3 and 3.4.
>
> My thoughts are: the issue is not brand new subject but improvement for
> current IDLE functionality.
> Added code cannot break any existing program/library I hope, it's related to
> humans who use IDLE only.
> It is desirable feature and probably IDLE users will be ok with new items in
> context menu even they are still 2.7 users.
>
> There are another opinion: it is new feature, not a bug, and the patch
> should be applied to 3.4 only.
>
> If you look on discussion for issue (http://bugs.python.org/issue1207589)
> you can see we cannot make decision, votes are split.
>
> I want to raise the question on this mailing list (as Terry Reedy suggested)
> to ask for community opinion.

The status quo is that IDLE is covered by the "no new features in
maintenance releases" rule along with the rest of the standard
library. Now, it may be *unreasonable* that this is so, and changing
it would help improve IDLE as a tool. The way to resolve a proposal
like that is to put it forward as a PEP, and explain the rationale for
treating IDLE differently. A PEP also makes it possible to state
exactly which modules are being proposed for exemption from the
no-new-features rule.

The fact that many (most?) distro packaging teams split idle out into
a separate package from their base python installation may be a point
in such a proposal's favour (e.g. in Fedora, there's a separate
"python-tools" package, so the main python package doesn't need to
depend on tkinter).

Until such a PEP has been submitted and approved, any feature
additions on maintenance branches should be reverted.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia


More information about the Python-Dev mailing list