Re: [Python-Dev] Removing IDLE from the standard library
I would like to propose removing IDLE from the standard library.
-1000. From the Python training department, I would like to say that this would be a horrible idea. Having taught numerous on-site training courses for Python, the one thing that I've learned is that you never know what you're going to get when you show up to teach a course. More often than not, you're thrown into some training room with a bunch of PCs, operated by someone who doesn't know anything about Python at all, and who had a hard enough time installing it in the first place. The fact that IDLE comes with Python means that even in such situations, as long as Python has been installed somewhere, there's going to be at least one halfway-reasonable environment for working with it (although I suppose there are some people who would still prefer to use the Windows command shell and Notepad). For what it's worth, I think IDLE works fine as a development environment, despite the fact that it has some flaky bits. The most annoying issue that I encounter in classes is people starting IDLE by right-clicking on files. This starts up IDLE without its subprocess and causes all sorts of bizarre problems related to the environment (e.g., restarting, module imports, etc.). Other than that, it's fine. Cheers, Dave
On Sun, Jul 11, 2010 at 2:16 PM, David Beazley <dave@dabeaz.com> wrote:
I would like to propose removing IDLE from the standard library.
-1000. From the Python training department, I would like to say that this would be a horrible idea. Having taught numerous on-site training courses for Python, the one thing that I've learned is that you never know what you're going to get when you show up to teach a course. More often than not, you're thrown into some training room with a bunch of PCs, operated by someone who doesn't know anything about Python at all, and who had a hard enough time installing it in the first place. The fact that IDLE comes with Python means that even in such situations, as long as Python has been installed somewhere, there's going to be at least one halfway-reasonable environment for working with it (although I suppose there are some people who would still prefer to use the Windows command shell and Notepad).
For what it's worth, I think IDLE works fine as a development environment, despite the fact that it has some flaky bits. The most annoying issue that I encounter in classes is people starting IDLE by right-clicking on files. This starts up IDLE without its subprocess and causes all sorts of bizarre problems related to the environment (e.g., restarting, module imports, etc.). Other than that, it's fine.
Cheers, Dave
Right. IDLE fits a niche. It's never going to be the world's best Python development environment but it isn't the worst either, and it's worth keeping around. There clearly are *some* folks who care enough about IDLE to submit bug reports and fixes. How about we empower these people by giving at least one of them commit privileges? IDLE development has often been done by people who aren't otherwise contributing to the core, and we surely should trust those folks with commit privileges. -- --Guido van Rossum (python.org/~guido)
On 11-7-2010 14:52, Guido van Rossum wrote:
On Sun, Jul 11, 2010 at 2:16 PM, David Beazley<dave@dabeaz.com> wrote:
I would like to propose removing IDLE from the standard library.
-1000. From the Python training department, I would like to say that this would be a horrible idea. Having taught numerous on-site training courses for Python, the one thing that I've learned is that you never know what you're going to get when you show up to teach a course. More often than not, you're thrown into some training room with a bunch of PCs, operated by someone who doesn't know anything about Python at all, and who had a hard enough time installing it in the first place. The fact that IDLE comes with Python means that even in such situations, as long as Python has been installed somewhere, there's going to be at least one halfway-reasonable environment for working with it (although I suppose there are some people who would still prefer to use the Windows command shell and Notepad).
For what it's worth, I think IDLE works fine as a development environment, despite the fact that it has some flaky bits. The most annoying issue that I encounter in classes is people starting IDLE by right-clicking on files. This starts up IDLE without its subprocess and causes all sorts of bizarre problems related to the environment (e.g., restarting, module imports, etc.). Other than that, it's fine.
Cheers, Dave
Right. IDLE fits a niche. It's never going to be the world's best Python development environment but it isn't the worst either, and it's worth keeping around.
There clearly are *some* folks who care enough about IDLE to submit bug reports and fixes. How about we empower these people by giving at least one of them commit privileges? IDLE development has often been done by people who aren't otherwise contributing to the core, and we surely should trust those folks with commit privileges.
Can I take a really big liberty and volunteer Terry Reedy for the job. Kindest regards. Mark Lawrence.
There clearly are *some* folks who care enough about IDLE to submit bug reports and fixes. How about we empower these people by giving at least one of them commit privileges? IDLE development has often been done by people who aren't otherwise contributing to the core, and we surely should trust those folks with commit privileges.
Can I take a really big liberty and volunteer Terry Reedy for the job.
It doesn't work that way. You can't volunteer somebody else (*). If Terry would volunteer himself, he'd get commit access in no time. Regards, Martin (*) so when you assign bugs to me, it probably means that they get less attention, not more.
On 11/07/2010 19:40, "Martin v. Löwis" wrote:
There clearly are *some* folks who care enough about IDLE to submit bug reports and fixes. How about we empower these people by giving at least one of them commit privileges? IDLE development has often been done by people who aren't otherwise contributing to the core, and we surely should trust those folks with commit privileges.
Can I take a really big liberty and volunteer Terry Reedy for the job.
It doesn't work that way. You can't volunteer somebody else (*).
If Terry would volunteer himself, he'd get commit access in no time.
Regards, Martin
(*) so when you assign bugs to me, it probably means that they get less attention, not more.
Martin, Thanks for your response. IIRC Terry Reedy has already volunteered to do this, if I'm incorrect I'll apologise right now to both of you. As for assigning bugs, I've been told to use the maintainer.rst list, so either the list is wrong, or I've had finger problems. If it's the latter I again say sorry. Kindest regards. Mark Lawrence
IIRC Terry Reedy has already volunteered to do this
Hmm. I don't recall that happening.
As for assigning bugs, I've been told to use the maintainer.rst list, so either the list is wrong, or I've had finger problems. If it's the latter I again say sorry.
I see. What copy have you been using specifically? I think I need to remove myself from these lists. Regards, Martin
On 12/07/2010 00:56, "Martin v. Löwis" wrote:
IIRC Terry Reedy has already volunteered to do this
Apologies to Terry if this is incorrect, but I believe this to be the case.
Hmm. I don't recall that happening.
As for assigning bugs, I've been told to use the maintainer.rst list, so either the list is wrong, or I've had finger problems. If it's the latter I again say sorry.
I see. What copy have you been using specifically? I think I need to remove myself from these lists.
Regards, Martin
Hi Martin, Again thanks for the response. I've been working from this:- http://svn.python.org/view/*checkout*/python/branches/py3k/Misc/maintainers.... It strikes me as being so sadly outdated that it's getting less than useless, or I assume that it's the same old case of not enough volunteers? Why did I bother. :) Kindest regards. Mark Lawrence.
On Sun, Jul 11, 2010 at 8:07 PM, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
I see. What copy have you been using specifically? I think I need to remove myself from these lists.
Regards, Martin
Hi Martin,
Again thanks for the response.
I've been working from this:- http://svn.python.org/view/*checkout*/python/branches/py3k/Misc/maintainers....
It strikes me as being so sadly outdated that it's getting less than useless, or I assume that it's the same old case of not enough volunteers? Why did I bother. :)
Kindest regards.
Mark Lawrence.
That file is too young to be out of date, and like I said, I've found the help useful Mark, so I wouldn't throw your hands up. That file should probably be updated/refreshed as people want, the idea behind it was to build a table of experts or people who voluntarily sign up to be the more active maintainers for a domain or standard library module. I maintain the idea is a good one - even if Martin wants off due to lack of time, it's important for people who are just coming in, such as Mark, to have some idea of where or *who* to talk to about something specific. We can obviously see the frightening number of gaps we have for "specific" maintainers. jesse
On Mon, 12 Jul 2010 01:07:54 +0100, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
I've been working from this:- http://svn.python.org/view/*checkout*/python/branches/py3k/Misc/maintainers....
It strikes me as being so sadly outdated that it's getting less than useless, or I assume that it's the same old case of not enough volunteers? Why did I bother. :)
As someone else mentioned, it is relatively new. It was created partially in the hopes that the huge gaps in coverage would encourage people to step forward and volunteer to be maintainers, and this has indeed been happening slowly. For example, Alexander Belopolsky recently became a committer and picked up datetime, time, and pickle. Another issue with the file that may make it look a tad outdated is that I think it hasn't been clear to everyone that it is designed to hold *tracker ids* rather than *committer ids*. I noticed the other day that I had to translate from committer id to tracker id for someone (I forget who, and I didn't have time to update the file at the time). -- R. David Murray www.bitdance.com
As for assigning bugs, I've been told to use the maintainer.rst list, so either the list is wrong, or I've had finger problems. If it's the latter I again say sorry.
I see. What copy have you been using specifically? I think I need to remove myself from these lists.
Regards, Martin Indeed it's not clear if the names that appear in the maintainers.rst
On 12/07/2010 2.56, "Martin v. Löwis" wrote: list are supposed to be added only to the nosy list or if it's possible to add them to the "assigned to" field too. A way to avoid confusion is to mark the names that should be added to the "Assigned to" field with a '*', and add the others to the nosy list only. E.g.: unicodedata loewis, lemburg, ezio.melotti* would mean "You can add loewis and lemburg to the nosy list and assign the issue to ezio.melotti". Otherwise we can just decide that those names should just be added to the nosy list and let them assign the issue to themselves if they want to fix it. Best Regards, Ezio Melotti
On Mon, 12 Jul 2010 13:39:15 +0300, Ezio Melotti <ezio.melotti@gmail.com> wrote:
On 12/07/2010 2.56, "Martin v. L=F6wis" wrote:
As for assigning bugs, I've been told to use the maintainer.rst list, so either the list is wrong, or I've had finger problems. If it's the latter I again say sorry.
I see. What copy have you been using specifically? I think I need to remove myself from these lists.
Regards, Martin
Indeed it's not clear if the names that appear in the maintainers.rst list are supposed to be added only to the nosy list or if it's possible to add them to the "assigned to" field too. A way to avoid confusion is to mark the names that should be added to the "Assigned to" field with a '*', and add the others to the nosy list only.
Actually it is clear. The text at the top of the file says the names are there "to be added to the nosy list". It does not mention assigning bugs. This was actually discussed at least briefly when the file was created. We probably should have included "*don't* assign tickets, nosy the maintainer and let them pick it up if they want to" in the intro text.
E.g.: unicodedata loewis, lemburg, ezio.melotti* would mean "You can add loewis and lemburg to the nosy list and assign the issue to ezio.melotti". Otherwise we can just decide that those
I like this suggestion, but obviously we need to let those developers who wish to do this "star" themselves. If there are no objections to this change to maintainers.rst, I'll start the ball rolling by marking myself for email, and adjusting the introductory text accordingly. -- R. David Murray www.bitdance.com
On 12/07/2010 12:42, R. David Murray wrote:
[snip...]
E.g.: unicodedata loewis, lemburg, ezio.melotti* would mean "You can add loewis and lemburg to the nosy list and assign the issue to ezio.melotti". Otherwise we can just decide that those
I like this suggestion, but obviously we need to let those developers who wish to do this "star" themselves.
If there are no objections to this change to maintainers.rst, I'll start the ball rolling by marking myself for email, and adjusting the introductory text accordingly.
Sounds good to me. You can leave me starred for unittest. Michael
-- R. David Murray www.bitdance.com _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.u...
-- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.
On 7/12/2010 7:42 AM, R. David Murray wrote: Another 'enhancement' might be to have a program occasionally email people with the items they are currently signed up for, to encourage editing.
-- R. David Murray www.bitdance.com
-- Terry Jan Reedy
On Sun, Jul 11, 2010 at 7:13 PM, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
Martin,
Thanks for your response.
IIRC Terry Reedy has already volunteered to do this, if I'm incorrect I'll apologise right now to both of you.
As for assigning bugs, I've been told to use the maintainer.rst list, so either the list is wrong, or I've had finger problems. If it's the latter I again say sorry.
Kindest regards.
Mark Lawrence
Hey Mark - I've noticed some of your cleanup/triaging in my bug queue at least (multiprocessing) and I thought I'd thank you - I didn't know who you were! jesse
On Mon, 12 Jul 2010 00:13:21 +0100, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
On 11/07/2010 19:40, "Martin v. L=F6wis" wrote:
There clearly are *some* folks who care enough about IDLE to submit bug reports and fixes. How about we empower these people by giving at least one of them commit privileges? IDLE development has often been done by people who aren't otherwise contributing to the core, and we surely should trust those folks with commit privileges.
Can I take a really big liberty and volunteer Terry Reedy for the job.
It doesn't work that way. You can't volunteer somebody else (*).
If Terry would volunteer himself, he'd get commit access in no time.
Regards, Martin
(*) so when you assign bugs to me, it probably means that they get less attention, not more.
Martin,
Thanks for your response.
IIRC Terry Reedy has already volunteered to do this, if I'm incorrect I'll apologise right now to both of you.
As for assigning bugs, I've been told to use the maintainer.rst list, so either the list is wrong, or I've had finger problems. If it's the latter I again say sorry.
I suggested you use maintainers.rst to find people to add to the nosy list, not to assign bugs to. But I can understand your confusion about that, given the name of the file, and the lack of complete process documentation. -- R. David Murray www.bitdance.com
On 7/11/2010 2:40 PM, "Martin v. Löwis" wrote: Guido
There clearly are *some* folks who care enough about IDLE to submit bug reports and fixes. How about we empower these people by giving at least one of them commit privileges? IDLE development has often been done by people who aren't otherwise contributing to the core, and we surely should trust those folks with commit privileges.
It appears Guiherme Polo already has commit privileges and just needs help exercising them, which I have offered, along with Martin's encouragement. Multiple IDLE maintainers would be even better. Mark Lawrence
Can I take a really big liberty and volunteer Terry Reedy for the job.
Thank you for the nomination.
If Terry would volunteer himself, he'd get commit access in no time.
What I specifically want right now is Commit Authorization Privilege, especially for IDLE, but in general would be fine. I am thinking about working working one or more 'beginners' who are 'shy' about acting independently, or who are not yet authorized to do so, and who would like help getting their feet 'wet', so to speak. I think I would enjoy this sort of pair development. In regard to IDLE, who, short of Guido, is in charge? Is there a design doc? It appears that several people have ideas in their heads, such as 'keep it simple'. Abstractly, I agree with that, but who decides what is simple, to the point of vetoing something as 'too complex'? -- Terry Jan Reedy
On 7/12/2010 2:05 AM, "Martin v. Löwis" wrote:
What I specifically want right now is Commit Authorization Privilege, especially for IDLE,
Not sure who could grant that, but as far as I can: you have it.
If I were approved to commit patches directly, then by implication I should be able to approve others doing the same. That is occasionally done now by others, but I wanted to be clear that for the present, the latter is all I could and would do. -- Terry Jan Reedy
On Mon, Jul 12 2010, Terry Reedy wrote:
On 7/12/2010 2:05 AM, "Martin v. Löwis" wrote:
What I specifically want right now is Commit Authorization Privilege, especially for IDLE,
Not sure who could grant that, but as far as I can: you have it.
If I were approved to commit patches directly, then by implication I should be able to approve others doing the same. That is occasionally done now by others, but I wanted to be clear that for the present, the latter is all I could and would do.
I've not had experience with patches from Terry. I don't think there are any in IDLE, at least not acknowledged in NEWS. I'd suggest giving him Tracker access and start out working with the patch submitters to update their patches to Py3, followed by a patch review and triage. He could unset all the bugs/patches assigned to me. I don't consider that I "own" IDLE. I've put quite a bit of time into it, and expect to continue. But I'd welcome help! I only hope to keep to roughly the same stylistic philosophy, and hope I'm still channeling Guido accurately. In addition, like the rest of the library, IDLE should be an example of good Python code. But there is some cruft in there. Some just old and/or unfinished, and some, like Multicall.py, rather obscure. Multicall is needed because Tk forgets what modifier keys were depressed when an event is generated. I'm hoping Tk will grow a memory so Multicall can be simplified. -- KBK
On 7/12/2010 10:49 PM, Kurt B. Kaiser wrote:
I've not had experience with patches from Terry. I don't think there are any in IDLE, at least not acknowledged in NEWS.
You posts in the last day have told me a lot more about you. Let me introduce myself to you in turn. I have been involved with Python and active on the lists for most of about 13 years. One of my first posts was to dub Python 'executable pseudocode'. I just helped with the preparation of a simple patch that fixes an IDLE annoyance I have. At the moment, I need for someone else to commit it. Will you do it? http://bugs.python.org/issue9222
I'd suggest giving him Tracker access
I have had that for perhaps five years. My first tracker post was http://bugs.python.org/issue593696 In that, I dianosed a problem and suggested a fix, which Neal Norwitz checked in. In the last month, I have touched perhaps 200 issues; about 20 are closed as a result. There are a few more that I think should be committed and closed. Overall, I have posted message to nearly 500 issues and adjusted headers on some number more. (I do not see a way to search for that with the provided form.) None the less, I have not said a word, until yesterday, in response to Martin's offer, which surprised me, about commit privileges for me. Last January, I turned down an offer, based on my tracker record, to be sponsored for such. I then thought it premature. I could hardly blame anyone who thought such today; I partly agree myself.
He could unset all the bugs/patches assigned to me.
So could you. Or you could find a real beginner to be your go-fer. Or you could ask a super-admin to save everyone (except himself) some time and do it with one SQL statement. (I am presuming that Roundup uses a real database under the web facade.)
I've put quite a bit of time into [IDLE] and expect to continue.
I am really glad to hear that. -- Terry Jan Reedy
On Mon, 12 Jul 2010 19:08:07 -0400 Terry Reedy <tjreedy@udel.edu> wrote:
On 7/12/2010 2:05 AM, "Martin v. Löwis" wrote:
What I specifically want right now is Commit Authorization Privilege, especially for IDLE,
Not sure who could grant that, but as far as I can: you have it.
If I were approved to commit patches directly, then by implication I should be able to approve others doing the same. That is occasionally done now by others, but I wanted to be clear that for the present, the latter is all I could and would do.
There is no formal approval process. If you post a review of a patch saying "the patch is ok" and the patch submitter is also a committer, he can then commit it himself. There is no need for more bureaucracy, and you don't need commit access to do this. Regards Antoine.
participants (11)
-
"Martin v. Löwis" -
Antoine Pitrou -
David Beazley -
Ezio Melotti -
Guido van Rossum -
Jesse Noller -
Kurt B. Kaiser -
Mark Lawrence -
Michael Foord -
R. David Murray -
Terry Reedy