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

[Andrew Svetlov]

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.

Thanks, Andrew Svetlov

[Nick Coghlan]

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 | ncog...@gmail.com | Brisbane, Australia
_______________________________________________
Python-Dev mailing list
Pytho...@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/dev-python%2Bgarchive-30976%40googlegroups.com

[R. David Murray]

On Sat, 03 Nov 2012 01:16:12 +1000, Nick Coghlan <ncog...@gmail.com> wrote:
> On Sat, Nov 3, 2012 at 12:46 AM, Andrew Svetlov
> <andrew....@gmail.com> wrote:
> > Hi. There are issue for subject: http://bugs.python.org/issue1207589

[...]

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

In this particular instance we are not looking to exempt the entire
module, just this changeset (because it does not change callable code).

Exempting IDLE in general is an interesting idea, but is not the immediate
question.

--David

[Terry Reedy]

On 11/2/2012 11:16 AM, Nick Coghlan wrote:
> On Sat, Nov 3, 2012 at 12:46 AM, Andrew Svetlov
> <andrew....@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

[Ned Deily]

In article <2012110215345...@webabinitio.net>,

"R. David Murray" <rdmu...@bitdance.com> wrote:

> On Sat, 03 Nov 2012 01:16:12 +1000, Nick Coghlan <ncog...@gmail.com> wrote:
> > On Sat, Nov 3, 2012 at 12:46 AM, Andrew Svetlov
> > <andrew....@gmail.com> wrote:
> > > Hi. There are issue for subject: http://bugs.python.org/issue1207589
> [...]
> > 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.
> In this particular instance we are not looking to exempt the entire
> module, just this changeset (because it does not change callable code).
>
> Exempting IDLE in general is an interesting idea, but is not the immediate
> question.

Also, as Roger Serwy has pointed out in the issue, the change also can
affect third-party IDLE extensions but he thinks the backport is still
worthwhile. Since the discussion has progressed primarily on the issue
tracker and the python-dev interest is probably limited, I would suggest
keeping the discussion over there rather than both here and there.

--
Ned Deily,
n...@acm.org

[Ned Deily]

In article <k70vuu$qi7$1...@ger.gmane.org>, Terry Reedy <tjr...@udel.edu>
wrote:

> For instance, the existence of a right-click context menu is not
> mentioned in the sketchy Library manual chapter for IDLE.

Actually, it is documented as of a few weeks ago (see the changes for
Issue10405). And the issue under discussion here updated both the
manual and the IDLE help file.

http://docs.python.org/2/library/idle.html#edit-context-menu

--
Ned Deily,
n...@acm.org

[Nick Coghlan]

On Sat, Nov 3, 2012 at 3:29 AM, Terry Reedy <tjr...@udel.edu> wrote:
>> 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.

If you don't want to run the risk of needing to rehash this discussion
every time an IDLE feature addition is made in maintenance branches,
write the rules down in a PEP.

I don't actually care all that much about IDLE (except in an abstract
"I know other people care about it" sense), but I *do* care about
developers being able to understand the rules about whether or not a
feature addition is permissible in a maintenance branch. That kind of
thing *cannot* be left to "oh, this change is OK, this change isn't,
but you needed to be around for this discussion that happened 5 years
ago in order to understand why", because it *wastes everybody's time*
explaining the unwritten rules to new developers. If there is a part
of the code base where new features are permitted in maintenance
branches, write them down, get agreement on them, and if anyone
complains "but that's a new feature on a maintenance branch", point
them to the PEP that says its OK.

Cheers,
Nick.

--
Nick Coghlan | ncog...@gmail.com | Brisbane, Australia

[Terry Reedy]

On 11/2/2012 10:04 PM, Nick Coghlan wrote:
> On Sat, Nov 3, 2012 at 3:29 AM, Terry Reedy <tjr...@udel.edu> wrote:
>>> 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.
>
> If you don't want to run the risk of needing to rehash this discussion
> every time an IDLE feature addition is made in maintenance branches,
> write the rules down in a PEP.

[snip reasons]
OK, I am convinced an info PEP would be a good idea.

--
Terry

[Nick Coghlan]

On Sat, Nov 3, 2012 at 1:10 PM, Terry Reedy <tjr...@udel.edu> wrote:
> [snip reasons]
> OK, I am convinced an info PEP would be a good idea.

Unless anyone objects, I'm happy to be BDFL-delegate for such a PEP. I
mainly want to ensure we clearly fence off "IDLE-the-application",
with (in effect) a 6 month release cycle synchronised across versions,
from the rest of the standard library.

Cheers,
Nick.

--
Nick Coghlan | ncog...@gmail.com | Brisbane, Australia

[Todd Rovito]

On Sat, Nov 3, 2012 at 5:28 AM, Nick Coghlan <ncog...@gmail.com> wrote:
> On Sat, Nov 3, 2012 at 1:10 PM, Terry Reedy <tjr...@udel.edu> wrote:
>> [snip reasons]
>> OK, I am convinced an info PEP would be a good idea.
>
> Unless anyone objects, I'm happy to be BDFL-delegate for such a PEP. I
> mainly want to ensure we clearly fence off "IDLE-the-application",
> with (in effect) a 6 month release cycle synchronised across versions,
> from the rest of the standard library.

I have not seen much progress on this issue so I thought I would
attempt to draft a PEP. This is my first PEP so go easy on me.

Attached is a PEP titled "IDLE Enhancement Exception for All
Branches", I am looking for feedback. Thanks.

[Nick Coghlan]

That's a good start - please forward it to the PEP editors list
(pe...@python.org) to be posted.

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". Mentioning the
point about Linux distros splitting it out into a separate package
would also be useful.

NY other two major comments:
- be specific about which parts of the code base are covered by the exception
- no need for extensive cross-OS testing prior to commit, that's a key
part of the role of the buildbots

Regards,

[Neil Hodgson]

Nick Coghlan:

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

Are the buildbots able to test UI features like menu selections?

Neil

[R. David Murray]

On Sun, 17 Feb 2013 14:00:24 +1100, Neil Hodgson <nyama...@me.com> wrote:
> Nick Coghlan:
>
> > - no need for extensive cross-OS testing prior to commit, that's a key
> > part of the role of the buildbots
>
> Are the buildbots able to test UI features like menu selections?

Not to mention that the test suite is a bit sparse for Idle, despite
recent efforts to improve this, even for the stuff that can be tested.

--David

[Nick Coghlan]

On Sun, Feb 17, 2013 at 4:56 PM, R. David Murray <rdmu...@bitdance.com> wrote:
> On Sun, 17 Feb 2013 14:00:24 +1100, Neil Hodgson <nyama...@me.com> wrote:
>> Nick Coghlan:
>>
>> > - no need for extensive cross-OS testing prior to commit, that's a key
>> > part of the role of the buildbots
>>
>> Are the buildbots able to test UI features like menu selections?
>
> Not to mention that the test suite is a bit sparse for Idle, despite
> recent efforts to improve this, even for the stuff that can be tested.

Perhaps something for the PEP to elaborate on before we declare open
season on Idle improvements in bug fix releases.

Cheers,

Nick.

--
Nick Coghlan | ncog...@gmail.com | Brisbane, Australia