Introducing PEP 434 -- IDLE Enhancement Exception for All Branches
Please see http://www.python.org/dev/peps/pep-0434/ for the complete PEP. The idea for the PEP was generated because a right click menu was added to IDLE in Python 2.7 this started a debate about bug fix VS enhancement see the PEP references for more information. IDLE has many patches that already exist but are difficult to get committed. This PEP is designed to make it easier to bring IDLE up to speed with modern GUI standards. The PEP is not perfect some issues that need to be solved: -How do we test IDLE patches to make sure they are high quality? Apparently the build bots don't test user interface issues. My philosophy is keep it simple so I was thinking that a simple procedure for testing on each of the major platforms should be performed before a commit. Creating a build bot that tests user interfaces seems difficult to me and could put IDLE improvements even more behind. -Does it make sense to separate IDLE from the stdlib for Python 3.4? I understand the batteries included argument, but if IDLE development is going to continue to proceed at a more accelerated pace than Python, it might make sense to separate it out into its own project or a sub-project. Please provide comments or other concerns. Thanks.
On Tue, Feb 19, 2013 at 09:48:16PM -0500, Todd Rovito wrote:
Personally, I don't use IDLE, but I know many people who do. I think it is important for them that IDLE remains in the std lib. We could have a stable version of IDLE in the std lib, and another version available on PyPI. The PyPI version could change more rapidly, since it doesn't have to fit in with the release schedule for the std lib. As the release schedule allows, the two branches could be merged. I have no idea if this has been tried before, but I think this would work better for an application like IDLE than for a library. -- Steven
On Thu, Feb 21, 2013 at 12:04 AM, Barry Warsaw <barry@python.org> wrote:
This was the plan for packaging vs distutils2, and I'll be proposing something similar for distlib, too. It can be a little tricky to manage at times, but you can do truly experimental features in the PyPI version first with a warning that they're experimental (e.g the various incarnations contextlib.ExitStack went through when I first added it to contextlib2), while bug fixes and features you're more confident about can go directly into hg.python.org and then be published early through the downstream project. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On 2/20/2013 9:30 AM, Nick Coghlan wrote:
Most of the actual issues that prompted this proposal are minor changes, such as to the find or replace dialog. Some might even be considered bug fixes rather than enhancements, depending on one's interpretation of the vague doc for such. This PEP is partly about whether we need to classify such changes, or just put them into whatever release we feel appropriate. Whatever the decision, those changes should directly go into whatever version they are going to go in. On the other hand, I agree that a PyPI preview release of a rewrite of IDLE to use the newer ttk widgets would be a good idea. But I personally would base such a project on 3.3 and consider whether it should require tcl/tk 8.6 rather than 8.5. And I would only put it in the stdlib in a new release (perhaps alongside the existing IDLE for at least one release). So this PEP is not relevance to such a project. -- Terry Jan Reedy
On Wed, 20 Feb 2013 17:07:57 -0500 Terry Reedy <tjreedy@udel.edu> wrote:
The only thing relevant to such a project is to find someone actually motivated to do it. What is IDLE's actual maintenance activity, exactly? I am sympathetic to the PEP but, really, thinking IDLE's development is hampered by Python's release process is *completely* ridiculous. If you want IDLE development to happen, please stop talking and start reviewing / committing patches. FTR, I'm personally +1 on yanking IDLE out of 3.4. Regards Antoine.
On 2/20/2013 6:12 PM, Antoine Pitrou wrote:
Right. That I what I was trying to say.
What is IDLE's actual maintenance activity, exactly?
I am not sure whether you are asking about volume or focus. A year ago, focus was on bugs that caused IDLE to quit because of an uncaught exception. When IDLE is started on Windows from an icon, this looks like a crash because there is no visible traceback or exit message. Recently, other issues have been worked on. In the last 5 months, activity has picked up and there are about 40 issues in 3.4 misc/news whose commit message contains 'idle'.
I am sympathetic to the PEP
Even though I am willing for the PEP to be rejected, great. I say this because I think it better for the community at large, even though a strict policy might be easier, on net, for developers.
but, really, thinking IDLE's development is hampered by Python's release process is *completely* ridiculous.
I do not believe I have said that and certainly have not meant to say that. What I have said or meant to say is that uncertainly and disagreement about how it does and should fit into the release process can be a hindrance.
If you want IDLE development to happen, please stop talking and start reviewing / committing patches.
I have, of course, done some of both in the past year, even if not currently. As I remember, the review process for at least one issue got hung up on whether a (small) change was a 'bugfix' or 'enhancement' and if the latter, whether it could go into all versions or just default. As we move from obvious bug issue to more ambiguous issues, this question would come up more often.
FTR, I'm personally +1 on yanking IDLE out of 3.4.
That would tend to keep 3.4 out of some classrooms. See, for example, http://search.gmane.org/?query=&author=Jean-Paul.Roy%40unice.fr&group=gmane.comp.python.idle&sort=relevance&DEFAULTOP=and&query= from a French college teacher. (The issue was fixed by a tk fix last March.) But of course, this is a different subject. -- Terry Jan Reedy
On 2/20/2013 8:44 PM, Andre Roberge wrote:
From what I have read on edu-sig, I believe it would be a huge mistake to remove IDLE from the Python standard library.
The idea was proposed 2 1/2 years ago, partly because IDLE was then buggy and mostly not maintained. The idea was rejected in favor of improving IDLE. Since then, many bugs have been quashed and idle is getting active attention. Do you have any idea what education users think about backporting IDLE enhancements? Would they support the PEP? Or would they rather only get true bugfixes in bugfix releases, even for IDLE? -- Terry Jan Reedy
On 2/20/2013 8:41 PM, Terry Reedy wrote:
On 2/20/2013 6:12 PM, Antoine Pitrou wrote:
Re-reading Todd's original post, I see that he did suggest that as a possibility. I expressed my disagreement with this red herring in a direct response to his post. -- Terry Jan Reedy
Hi Antoine, I am the developer of the IdleX project (http://idlex.sourceforge.net). It's not a fork of IDLE, but just a collection of extensions that can be easily merged into IDLE. I started the project because of the slow pace of IDLE development, especially when having several outstanding patches languishing in the bug tracker. With your help I'd like to push IDLE forward. - Roger
Hello Roger, Le Wed, 20 Feb 2013 20:45:04 -0600, serwy <roger.serwy@gmail.com> a écrit :
I guess it's a good idea to try and merge improvements into IDLE, but IDLE developers such as Terry would be in a better position to answer. Regards Antoine.
On 2/21/2013 4:21 AM, Antoine Pitrou wrote:
I guess it's a good idea to try and merge improvements into IDLE, but IDLE developers such as Terry would be in a better position to answer.
The pace of reviewing and applying patches to the default branch is a functions of people's time. I admit that I have been slower than I would like to be. This PEP is strictly about the question of which patches applied to tip should also be applied to older branches. A clearer answer, whatever it is, will help me, at least, to get more done. If some enhancements are backported to bug-fix releases, they may appear in the wild sooner. On the other hand, not backporting might mean that more total patches get applied to default before the next release. On the third hand, it can be easier to get a patch widely tested on existing releases than on newly built default. (This is true on Windows where _tkinter is not compiled without considerable extra work.) -- Terry Jan Reedy
On Feb 20, 2013, at 6:04, Barry Warsaw <barry@python.org> wrote:
And sqlite3. Personally, I've found it easier to track down certain changes in sqlite3 than in other modules. The Python docs are very clear about when a new function was added, but not always as clear about, e.g., performance characteristics or internal behavior with indirect external effects. I've found it easier in some cases to find that I'm relying on, say, pysqlite >= 2.5.0 behavior than python >= 2.6. And then mapping pysqlite >= 2.5.0 to Python versions is easy. And this might be even more relevant for IDLE than for a module. And of course it gives me a way to deal with the changes. On a machine that has 2.5, I can just pip install pysqlite. And I can certainly see it being useful to pip-3.3 install idle to get IDLE 3.4.1 on a machine with python 3.3. I don't think these are _major_ selling points, but they're at least minor ones, which may help counter the obvious downside (merging isn't free).
Separate set of rules for features classified as "standard applications" versus "standard libraries"?
On 2/19/2013 9:48 PM, Todd Rovito wrote:
In my view, the PEP is definitely about allowing minor enhancements to existing features in bugfix releases. It is maybe about backporting new features such as would require a new entry on the menus. The right-click menu does not fit either category but it is more like the latter. In any case, I think it is an innocuous addition and should be allowed if a committer wants to do the backport. I do not think the PEP should be a blank check to backport currently hypothetical major revisions such a themed widgets or tabbed windows. If and when such a thing is tested and ready to be put into the 'next' version, the possibility of backporting it should be a separate discussion.
-How do we test IDLE patches to make sure they are high quality?
This is a separate issue from the PEP. Those of us who have and are working on IDLE issues are aware of the need to test on Windows, Linux, and Mac, and to test 2.7 separately from 3.x. There is a tracker issue for improving IDLE tests.
-Does it make sense to separate IDLE from the stdlib for Python 3.4?
Not to me.
We typically release bugfixes about every 6-9 months and I think that is often enough to release changes. The subject of the PEP is what should go into those releases. -- Terry Jan Reedy
On Tue, Feb 19, 2013 at 09:48:16PM -0500, Todd Rovito wrote:
Personally, I don't use IDLE, but I know many people who do. I think it is important for them that IDLE remains in the std lib. We could have a stable version of IDLE in the std lib, and another version available on PyPI. The PyPI version could change more rapidly, since it doesn't have to fit in with the release schedule for the std lib. As the release schedule allows, the two branches could be merged. I have no idea if this has been tried before, but I think this would work better for an application like IDLE than for a library. -- Steven
On Thu, Feb 21, 2013 at 12:04 AM, Barry Warsaw <barry@python.org> wrote:
This was the plan for packaging vs distutils2, and I'll be proposing something similar for distlib, too. It can be a little tricky to manage at times, but you can do truly experimental features in the PyPI version first with a warning that they're experimental (e.g the various incarnations contextlib.ExitStack went through when I first added it to contextlib2), while bug fixes and features you're more confident about can go directly into hg.python.org and then be published early through the downstream project. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On 2/20/2013 9:30 AM, Nick Coghlan wrote:
Most of the actual issues that prompted this proposal are minor changes, such as to the find or replace dialog. Some might even be considered bug fixes rather than enhancements, depending on one's interpretation of the vague doc for such. This PEP is partly about whether we need to classify such changes, or just put them into whatever release we feel appropriate. Whatever the decision, those changes should directly go into whatever version they are going to go in. On the other hand, I agree that a PyPI preview release of a rewrite of IDLE to use the newer ttk widgets would be a good idea. But I personally would base such a project on 3.3 and consider whether it should require tcl/tk 8.6 rather than 8.5. And I would only put it in the stdlib in a new release (perhaps alongside the existing IDLE for at least one release). So this PEP is not relevance to such a project. -- Terry Jan Reedy
On Wed, 20 Feb 2013 17:07:57 -0500 Terry Reedy <tjreedy@udel.edu> wrote:
The only thing relevant to such a project is to find someone actually motivated to do it. What is IDLE's actual maintenance activity, exactly? I am sympathetic to the PEP but, really, thinking IDLE's development is hampered by Python's release process is *completely* ridiculous. If you want IDLE development to happen, please stop talking and start reviewing / committing patches. FTR, I'm personally +1 on yanking IDLE out of 3.4. Regards Antoine.
On 2/20/2013 6:12 PM, Antoine Pitrou wrote:
Right. That I what I was trying to say.
What is IDLE's actual maintenance activity, exactly?
I am not sure whether you are asking about volume or focus. A year ago, focus was on bugs that caused IDLE to quit because of an uncaught exception. When IDLE is started on Windows from an icon, this looks like a crash because there is no visible traceback or exit message. Recently, other issues have been worked on. In the last 5 months, activity has picked up and there are about 40 issues in 3.4 misc/news whose commit message contains 'idle'.
I am sympathetic to the PEP
Even though I am willing for the PEP to be rejected, great. I say this because I think it better for the community at large, even though a strict policy might be easier, on net, for developers.
but, really, thinking IDLE's development is hampered by Python's release process is *completely* ridiculous.
I do not believe I have said that and certainly have not meant to say that. What I have said or meant to say is that uncertainly and disagreement about how it does and should fit into the release process can be a hindrance.
If you want IDLE development to happen, please stop talking and start reviewing / committing patches.
I have, of course, done some of both in the past year, even if not currently. As I remember, the review process for at least one issue got hung up on whether a (small) change was a 'bugfix' or 'enhancement' and if the latter, whether it could go into all versions or just default. As we move from obvious bug issue to more ambiguous issues, this question would come up more often.
FTR, I'm personally +1 on yanking IDLE out of 3.4.
That would tend to keep 3.4 out of some classrooms. See, for example, http://search.gmane.org/?query=&author=Jean-Paul.Roy%40unice.fr&group=gmane.comp.python.idle&sort=relevance&DEFAULTOP=and&query= from a French college teacher. (The issue was fixed by a tk fix last March.) But of course, this is a different subject. -- Terry Jan Reedy
From what I have read on edu-sig, I believe it would be a huge mistake to remove IDLE from the Python standard library.
On Wed, Feb 20, 2013 at 9:41 PM, Terry Reedy <tjreedy@udel.edu> wrote:
On 2/20/2013 8:44 PM, Andre Roberge wrote:
From what I have read on edu-sig, I believe it would be a huge mistake to remove IDLE from the Python standard library.
The idea was proposed 2 1/2 years ago, partly because IDLE was then buggy and mostly not maintained. The idea was rejected in favor of improving IDLE. Since then, many bugs have been quashed and idle is getting active attention. Do you have any idea what education users think about backporting IDLE enhancements? Would they support the PEP? Or would they rather only get true bugfixes in bugfix releases, even for IDLE? -- Terry Jan Reedy
On 2/20/2013 8:41 PM, Terry Reedy wrote:
On 2/20/2013 6:12 PM, Antoine Pitrou wrote:
Re-reading Todd's original post, I see that he did suggest that as a possibility. I expressed my disagreement with this red herring in a direct response to his post. -- Terry Jan Reedy
Hi Antoine, I am the developer of the IdleX project (http://idlex.sourceforge.net). It's not a fork of IDLE, but just a collection of extensions that can be easily merged into IDLE. I started the project because of the slow pace of IDLE development, especially when having several outstanding patches languishing in the bug tracker. With your help I'd like to push IDLE forward. - Roger
Hello Roger, Le Wed, 20 Feb 2013 20:45:04 -0600, serwy <roger.serwy@gmail.com> a écrit :
I guess it's a good idea to try and merge improvements into IDLE, but IDLE developers such as Terry would be in a better position to answer. Regards Antoine.
On 2/21/2013 4:21 AM, Antoine Pitrou wrote:
I guess it's a good idea to try and merge improvements into IDLE, but IDLE developers such as Terry would be in a better position to answer.
The pace of reviewing and applying patches to the default branch is a functions of people's time. I admit that I have been slower than I would like to be. This PEP is strictly about the question of which patches applied to tip should also be applied to older branches. A clearer answer, whatever it is, will help me, at least, to get more done. If some enhancements are backported to bug-fix releases, they may appear in the wild sooner. On the other hand, not backporting might mean that more total patches get applied to default before the next release. On the third hand, it can be easier to get a patch widely tested on existing releases than on newly built default. (This is true on Windows where _tkinter is not compiled without considerable extra work.) -- Terry Jan Reedy
On Feb 20, 2013, at 6:04, Barry Warsaw <barry@python.org> wrote:
And sqlite3. Personally, I've found it easier to track down certain changes in sqlite3 than in other modules. The Python docs are very clear about when a new function was added, but not always as clear about, e.g., performance characteristics or internal behavior with indirect external effects. I've found it easier in some cases to find that I'm relying on, say, pysqlite >= 2.5.0 behavior than python >= 2.6. And then mapping pysqlite >= 2.5.0 to Python versions is easy. And this might be even more relevant for IDLE than for a module. And of course it gives me a way to deal with the changes. On a machine that has 2.5, I can just pip install pysqlite. And I can certainly see it being useful to pip-3.3 install idle to get IDLE 3.4.1 on a machine with python 3.3. I don't think these are _major_ selling points, but they're at least minor ones, which may help counter the obvious downside (merging isn't free).
Separate set of rules for features classified as "standard applications" versus "standard libraries"?
On 2/19/2013 9:48 PM, Todd Rovito wrote:
In my view, the PEP is definitely about allowing minor enhancements to existing features in bugfix releases. It is maybe about backporting new features such as would require a new entry on the menus. The right-click menu does not fit either category but it is more like the latter. In any case, I think it is an innocuous addition and should be allowed if a committer wants to do the backport. I do not think the PEP should be a blank check to backport currently hypothetical major revisions such a themed widgets or tabbed windows. If and when such a thing is tested and ready to be put into the 'next' version, the possibility of backporting it should be a separate discussion.
-How do we test IDLE patches to make sure they are high quality?
This is a separate issue from the PEP. Those of us who have and are working on IDLE issues are aware of the need to test on Windows, Linux, and Mac, and to test 2.7 separately from 3.x. There is a tracker issue for improving IDLE tests.
-Does it make sense to separate IDLE from the stdlib for Python 3.4?
Not to me.
We typically release bugfixes about every 6-9 months and I think that is often enough to release changes. The subject of the PEP is what should go into those releases. -- Terry Jan Reedy
participants (10)
-
Andre Roberge -
Andrew Barnert -
Antoine Pitrou -
Barry Warsaw -
Daniel Holth -
Nick Coghlan -
serwy -
Steven D'Aprano -
Terry Reedy -
Todd Rovito