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

[Terry Reedy]

On 11/2/2012 11:16 AM, Nick Coghlan wrote:
> 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.

That may be your opinion, but I disagree that the situation is so clear. 
In what PEP (or other document) is the above stated.

IDLE has previously been treated here as an exception to the normal 
rules. Two years ago, we debated *dropping* IDLE from the distribution 
-- beginning with the next release. We would not have had such a 
discussion for any normal library module as simply removing a module 
before Py 4 is against policy.

 > Now, it may be *unreasonable* that this is so, and changing
> it would help improve IDLE as a tool.

If it is 'unreasonable', then perhaps it is not so.

 > 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 seems like overkill to me. The matter is a rule clarification, not 
an enhancement proposal. The rationale is simple.

1. The reason for the no-new-features rule does not apply to user 
interface features, certainly not to the right-click context menu.

2. Users will prefer consistency, especially in something like 
right-click behavior (or search/replace boxes, etc).

3. It is often unclear whether a particular change is a fix or an 
enhancement. I would suggest that a) in many cases neither word really 
applies and b) in such cases, given 1) and 2) above, it is not worth the 
effort to force fit a change into either category.

For instance, the existence of a right-click context menu is not 
mentioned in the sketchy Library manual chapter for IDLE. So there can 
neither be consistency nor inconsistency between current behavior and 
the non-existent doc entry. Hence, there is no objective standard for 
classifying a change, and hence there is disagreement. Since
http://bugs.python.org/issue1207589
brings IDLE in line with external standards, I consider it a bug fix. 
Actually, I consider it *both* a bug fix *and* and enhancement, but a 
bug fix for the purpose of deciding where to apply it (given that 
someone, Andrew, was willing to go though the effort of applying it 
everywhere).

Even features that are documented as to existence are not specified. The 
following is typical.
   "Find...
   Open a search dialog box with many options"
There have been or still are proposed changes to Find or Replace that 
could be classified either way, depending on whether, in the absence of 
any specification, one is inclined to make 'bug fix' or 'enhancement' 
the default choice.

> A PEP also makes it possible to state
> exactly which modules are being proposed for exemption from the
> no-new-features rule.

Since the proposal two years ago was to delete the entire idlelib/* 
package, I would start with the entire package. If and when possibly 
generally useful modules (perhaps idlelib/rpc.py -- remote procedure 
calls) are documented for general use, they should be versioned. But 
then they should perhaps be moved elsewhere.

> 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.

And who shall decide what change is what?

-- 
Terry Jan Reedy