[Python-Dev] Cut/Copy/Paste items in IDLE right click context menu
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 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Cut/Copy/Paste items in IDLE right click context menu
On Sat, Nov 3, 2012 at 12:46 AM, Andrew Svetlov 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 | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Cut/Copy/Paste items in IDLE right click context menu
On Sat, 03 Nov 2012 01:16:12 +1000, Nick Coghlan wrote: > On Sat, Nov 3, 2012 at 12:46 AM, Andrew Svetlov > 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 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2012-10-26 - 2012-11-02) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open3804 (-19) closed 24361 (+77) total 28165 (+58) Open issues with patches: 1714 Issues opened (29) == #9742: Python 2.7: math module fails to build on Solaris 9 http://bugs.python.org/issue9742 reopened by mark.dickinson #15478: UnicodeDecodeError on OSError on Windows with undecodable (byt http://bugs.python.org/issue15478 reopened by skrah #16218: Python launcher does not support non ascii characters http://bugs.python.org/issue16218 reopened by jcea #16333: Trailing whitespace in json dump when using indent http://bugs.python.org/issue16333 opened by zach.mathew #16334: Faster unicode-escape and raw-unicode-escape codecs http://bugs.python.org/issue16334 opened by serhiy.storchaka #16335: Integer overflow in unicode-escape decoder http://bugs.python.org/issue16335 opened by serhiy.storchaka #16336: Check input in surrogatepass error handler http://bugs.python.org/issue16336 opened by serhiy.storchaka #16338: pysnmp/asyncore - timeout ineffective? http://bugs.python.org/issue16338 opened by Trenton.Craig #16339: Document "exec(stmt, global_dict, local_dict)" form in Python http://bugs.python.org/issue16339 opened by mark.dickinson #16346: readline problem http://bugs.python.org/issue16346 opened by mathieu37 #16347: configure.ac patch http://bugs.python.org/issue16347 opened by cavallo71 #16349: Document whether it's safe to use bytes for struct format stri http://bugs.python.org/issue16349 opened by takluyver #16350: zlib.Decompress.decompress() after EOF discards existing value http://bugs.python.org/issue16350 opened by nadeem.vawda #16353: add function to os module for getting path to default shell http://bugs.python.org/issue16353 opened by chris.jerdonek #16354: Remember python version choice on docs.python.org http://bugs.python.org/issue16354 opened by wichert #16355: inspect.getcomments() does not work in the interactive shell http://bugs.python.org/issue16355 opened by marco.buttu #16357: SSLSocket created from SSLContext.wrap_socket doesn't include http://bugs.python.org/issue16357 opened by mcjeff #16360: argparse: comma in metavar causes assertion failure when forma http://bugs.python.org/issue16360 opened by bgamari #16361: HTTPS/TLS Problem in Python 3.3 http://bugs.python.org/issue16361 opened by pventura #16367: io.FileIO.readall() is not 64-bit safe on Windows http://bugs.python.org/issue16367 opened by haypo #16376: wrong type for wintypes.BYTE http://bugs.python.org/issue16376 opened by techtonik #16378: venv.EnvBuilder docstring inconsistencies http://bugs.python.org/issue16378 opened by bfroehle #16379: SQLite error code not exposed to python http://bugs.python.org/issue16379 opened by torsten #16381: Introduce option to force the interpreter to exit upon MemoryE http://bugs.python.org/issue16381 opened by ctheune #16382: Better warnings exception for bad category http://bugs.python.org/issue16382 opened by pelson #16383: Python 3.3 Permission Error with User Library on Windows http://bugs.python.org/issue16383 opened by jimp02 #16384: import.c doesn't handle EOFError from PyMarshal_Read* http://bugs.python.org/issue16384 opened by syeberman #16385: evaluating literal dict with repeated keys gives no warnings/e http://bugs.python.org/issue16385 opened by Albert.Ferras #16386: imp.find_module does not specify registry key it searches on w http://bugs.python.org/issue16386 opened by dhgmgn Most recent 15 issues with no replies (15) == #16386: imp.find_module does not specify registry key it searches on w http://bugs.python.org/issue16386 #16384: import.c doesn't handle EOFError from PyMarshal_Read* http://bugs.python.org/issue16384 #16382: Better warnings exception for bad category http://bugs.python.org/issue16382 #16379: SQLite error code not exposed to python http://bugs.python.org/issue16379 #16376: wrong type for wintypes.BYTE http://bugs.python.org/issue16376 #16360: argparse: comma in metavar causes assertion failure when forma http://bugs.python.org/issue16360 #16353: add function to os module for getting path to default shell http://bugs.python.org/issue16353 #16347: configure.ac patch http://bugs.python.org/issue16347 #16346: readline problem http://bugs.python.org/issue16346 #16339: Document "exec(stmt, global_dict, local_dict)" form in Python http://bugs.python.org/issue16339 #16334: Faster unicode-escape and raw-unicode-escape codecs http://bugs.python.org/issue16334 #16321: Move eq.h out of stringlib http://bugs.python.org/issue16321 #16320: Establish order in bytes/string dependencies http://bugs.python.org/issue16320 #16287: Sporadic test_utime() failures on Solaris http://bugs.python.org/issue16287 #16
Re: [Python-Dev] Cut/Copy/Paste items in IDLE right click context menu
On 11/2/2012 11:16 AM, Nick Coghlan wrote: On Sat, Nov 3, 2012 at 12:46 AM, Andrew Svetlov 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 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Cut/Copy/Paste items in IDLE right click context menu
In article <[email protected]>, "R. David Murray" wrote: > On Sat, 03 Nov 2012 01:16:12 +1000, Nick Coghlan wrote: > > On Sat, Nov 3, 2012 at 12:46 AM, Andrew Svetlov > > 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, [email protected] ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Cut/Copy/Paste items in IDLE right click context menu
In article , Terry Reedy 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, [email protected] ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3.3 vs. Python 2.7 benchmark results (again, but this time more solid numbers)
Issue filed for the performance issue: http://bugs.python.org/issue16390 With that change and running on tip of Mako on my laptop now reports 1.25x slower which is *much* better than it was. This performance issue might also explain why all of the regex compilation benchmarks are worse under Python 3.3 by a decent margin. On Fri, Nov 2, 2012 at 2:16 PM, Philip Jenvey wrote: > lru_cache on re._compile_typed ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Summary of Python tracker Issues
On Fri, Nov 2, 2012 at 11:07 AM, Python tracker wrote: > > ACTIVITY SUMMARY (2012-10-26 - 2012-11-02) > Python tracker at http://bugs.python.org/ > > To view or respond to any of the issues listed below, click on the issue. > Do NOT respond to this message. > > Issues counts and deltas: > open3804 (-19) wow! > closed 24361 (+77) > total 28165 (+58) > > Open issues with patches: 1714 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Summary of Python tracker Issues
On Fri, Nov 2, 2012 at 10:05 PM, Eric Snow wrote: > > On Fri, Nov 2, 2012 at 11:07 AM, Python tracker wrote: > > > > ACTIVITY SUMMARY (2012-10-26 - 2012-11-02) > > Python tracker at http://bugs.python.org/ > > > > To view or respond to any of the issues listed below, click on the issue. > > Do NOT respond to this message. > > > > Issues counts and deltas: > > open3804 (-19) > > wow! > Aha! > > > closed 24361 (+77) > > total 28165 (+58) > > > > Open issues with patches: 1714 > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: http://mail.python.org/mailman/options/python-dev/andrew.svetlov%40gmail.com -- Thanks, Andrew Svetlov ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Cut/Copy/Paste items in IDLE right click context menu
On Sat, Nov 3, 2012 at 3:29 AM, Terry Reedy 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 | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Cut/Copy/Paste items in IDLE right click context menu
On 11/2/2012 10:04 PM, Nick Coghlan wrote: On Sat, Nov 3, 2012 at 3:29 AM, Terry Reedy 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 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
