Most CPython tracker issues are classified as behavior or enhancement.Most behavior patches are backported to branches for existingversions. Enhancement patches are restricted to the default branchthat becomes the next Python version.
This PEP proposes that the restriction on applying enhancements berelaxed for IDLE code, residing in …/Lib/idlelib/. In practice,this would mean that IDLE developers would not have to classify oragree on the classification of a patch but could instead focus on whatis best for IDLE users and future IDLE development. It would alsomean that IDLE patches would not necessarily have to be split into‘bugfix’ changes and enhancement changes.
The PEP would apply to changes in existing features and addition ofsmall features, such as would require a new menu entry, but notnecessarily to possible major re-writes such as switching to themedwidgets or tabbed windows.
This PEP was prompted by controversy on both the tracker and pydevlist over adding Cut, Copy, and Paste to right-click context menus(Issue 1207589, opened in 2005[1]; pydev thread[2]). The featureswere available as keyboard shortcuts but not on the context menu. Itis standard, at least on Windows, that they should be when applicable(a read-only window would only have Copy), so users do not have toshift to the keyboard after selecting text for cutting or copying or aslice point for pasting. The context menu was not documented until 10days before the new options were added (Issue 10405[5]).
Normally, behavior is called a bug if it conflicts with documentationjudged to be correct. But if there is no doc, what is the standard?If the code is its own documentation, most IDLE issues on the trackerare enhancement issues. If we substitute reasonable user expectation,(which can, of course, be its own subject of disagreement), many moreissues are behavior issues.
For context menus, people disagreed on the status of the additions –bugfix or enhancement. Even people who called it an enhancementdisagreed as to whether the patch should be backported. This PEPproposes to make the status disagreement irrelevant by explicitlyallowing more liberal backporting than for other stdlib modules.
Python does have many advanced features yet Python is well known forbeing an easy computer language for beginners[3]. A major Pythonphilosophy is “batteries included” which is best demonstrated inPython’s standard library with many modules that are not typicallyincluded with other programming languages[4]. IDLE is an important“battery” in the Python toolbox because it allows a beginner to getstarted quickly without downloading and configuring a third party IDE.IDLE represents a commitment by the Python community to encouage theuse of Python as a teaching language both inside and outside of formaleducational settings. The recommended teaching experience is to havea learner start with IDLE. This PEP and the work that it will enablewill allow the Python community to make that learner’s experience withIDLE awesome by making IDLE a simple tool for beginners to get startedwith Python.
People primarily use IDLE by running the graphical user interface(GUI) application, rather than by directly importing the effectivelyprivate (undocumented) implementation modules in idlelib. Whetherthey use the shell, the editor, or both, we believe they will benefitmore from consistency across the latest releases of current Pythonversions than from consistency within the bugfix releases for onePython version. This is especially true when existing behavior isclearly unsatisfactory.
When people use the standard interpreter, the OS-provided frame worksthe same for all Python versions. If, for instance, Microsoft were toupgrade the Command Prompt GUI, the improvements would be presentregardless of which Python were running within it. Similarly, if oneedits Python code with editor X, behaviors such as the right-clickcontext menu and the search-replace box do not depend on the versionof Python being edited or even the language being edited.
The benefit for IDLE developers is mixed. On the one hand, testingmore versions and possibly having to adjust a patch, especially for2.7, is more work. (There is, of course, the option on notbackporting everything. For issue 12510, some changes to calltips forclasses were not included in the 2.7 patch because of issues withold-style classes[6].) On the other hand, bike-shedding can be anenergy drain. If the obvious fix for a bug looks like an enhancement,writing a separate bugfix-only patch is more work. And making thecode diverge between versions makes future multi-version patches moredifficult.
These issue are illustrated by the search-and-replace dialog box. Itused to raise an exception for certain user entries[7]. Theuncaught exception caused IDLE to exit. At least on Windows, the exitwas silent (no visible traceback) and looked like a crash if IDLE wasstarted normally, from an icon.
Was this a bug? IDLE Help (on the current Help submenu) just says“Replace… Open a search-and-replace dialog box”, and a boxwasopened. It is not, in general, a bug for a library method to raise anexception. And it is not, in general, a bug for a library method toignore an exception raised by functions it calls. So if we were toadopt the ‘code = doc’ philosophy in the absence of detailed docs, onemight say ‘No’.
However, IDLE exiting when it does not need to is definitelyobnoxious. So four of us agreed that it should be prevented. Butthere was still the question of what to do instead? Catch theexception? Just not raise the exception? Beep? Display an errormessage box? Or try to do something useful with the user’s entry?Would replacing a ‘crash’ with useful behavior be an enhancement,limited to future Python releases? Should IDLE developers have to askthat?
For IDLE, there are three types of users who might be concerned aboutback compatibility. First are people who run IDLE as an application.We have already discussed them above.
Second are people who import one of the idlelib modules. As far as weknow, this is only done to start the IDLE application, and we do notpropose breaking such use. Otherwise, the modules are undocumentedand effectively private implementations. If an IDLE module weredefined as public, documented, and perhaps moved to the tkinterpackage, it would then follow the normal rules. (Documenting theprivate interfaces for the benefit of people working on the IDLE codeis a separate issue.)
Third are people who write IDLE extensions. The guaranteed extensioninterface is given in idlelib/extension.txt. This should be respectedat least in existing versions, and not frivolously changed in futureversions. But there is a warning that “The extension cannot assumemuch about this [EditorWindow] argument.” This guarantee shouldrarely be an issue with patches, and the issue is not specific to‘enhancement’ versus ‘bugfix’ patches.
As is happens, after the context menu patch was applied, it came upthat extensions that added items to the context menu (rare) would bebroken because the patch a) added a new item to standard rmenu_specsand b) expected every rmenu_spec to be lengthened. It is not clearwhether this violates the guarantee, but there is a second patch thatfixes assumption b). It should be applied when it is clear that thefirst patch will not have to be reverted.
This document has been placed in the public domain.
Source:https://github.com/python/peps/blob/main/peps/pep-0434.rst
Last modified:2025-02-01 08:59:27 GMT