Hello, I would like to propose removing IDLE from the standard library. I have been using IDLE since 2002 and have been doing my best to help maintain and further develop IDLE since 2005. In recent years IDLE has received negligible interest and attention from the Python community. During this time IDLE has slowly gone downhill. The documentation and tutorials grow increasingly out of date. Cross-platform support has degraded with the increasing popularity of OSX and 64-bit platforms. Bugs take months, and sometimes more than a year, to be solved. Features that have since become common-place, such as having a non-intrusive search box instead of a dialog, are obviously and painfully lacking, making IDLE feel clumsy and out-dated. For these reasons, I think it would be fitting to remove IDLE from the standard library. IDLE is no longer recommended to beginners, IMO rightfully so, and this was the main reason for its inclusion in the standard library. Furthermore, if there is little or no interest in developing and maintaining IDLE, it should be removed to avoid having buggy and badly supported software in the standard library. - Tal Einat
On 7/10/2010 7:05 PM, Tal Einat wrote:
Hello,
I would like to propose removing IDLE from the standard library.
-1 I use it daily. On Windows, it works better in many ways than the awful interactive command window, which I almost never use. I would rather the latter be replaced.
I have been using IDLE since 2002 and have been doing my best to help maintain and further develop IDLE since 2005.
In recent years IDLE has received negligible interest and attention from the Python community. During this time IDLE has slowly gone downhill.
I would say that it has not gone uphill.
The documentation and tutorials grow increasingly out of date. Cross-platform support has degraded with the increasing popularity of OSX and 64-bit platforms.
Does it not work with the 64bit Windows build?
Bugs take months, and sometimes more than a year, to be solved.
The problem here, it seems to me, is that all issues are autoassigned to an inactive person (KBK) who does not really accept them except once a year or so. I do not know whether all other commiter are unwilling to commit IDLE issues, no matter how obvious and trivial, or if they all think they 'belong' to KBK. If and when I get a development setup, learn how to apply patches, and get commit privileges, I would want to be able to work on IDLE issues.
Features that have since become common-place, such as having a non-intrusive search box instead of a dialog, are obviously and painfully lacking, making IDLE feel clumsy and out-dated.
I do not know what you mean here, so the 'lack' is completely unobvious and non-painful to me. The IDLE search/replace box strikes as being as good as that I have seen with other Windows software.
For these reasons, I think it would be fitting to remove IDLE from the standard library. IDLE is no longer recommended to beginners, IMO rightfully so, and this was the main reason for its inclusion in the standard library.
Is there a superiour replacement that you would recommend to be packaged with the Windows distribution? It would have to have a shell replacement also.
Furthermore, if there is little or no interest in developing and maintaining IDLE, it should be removed to avoid having buggy and badly supported software in the standard library.
For my day to day use of the shell and editor, there are no serious bugs. -- Terry Jan Reedy
On Sat, 10 Jul 2010 21:33:28 -0400 Terry Reedy <tjreedy@udel.edu> wrote:
The problem here, it seems to me, is that all issues are autoassigned to an inactive person (KBK) who does not really accept them except once a year or so. I do not know whether all other commiter are unwilling to commit IDLE issues, no matter how obvious and trivial, or if they all think they 'belong' to KBK.
Well, how can you expect people to commit patches for something they don't know or use? (and, admittedly, something many of us don't care about) Regards Antoine.
Hello Tal,
I would like to propose removing IDLE from the standard library. -1. One of the biggest "selling points" for me when switching to python was the "out of the box" working IDE with REPL, syntax highliting and a debugger. The only other candidate I think of to replace IDLE might be IPython. However for novice users who are not used to command line it might be too intimidating.
Cross-platform support has degraded with the increasing popularity of OSX and 64-bit platforms. I use IDLE on Ubuntu 64bit and before that on OS X 64 bit, never had a
There are my others IDEs out there, some better some worse. However IMO to have one bundled with Python is highly important. problem. Can you give some examples on what do you mean by "cross-platform support"? All the best, -- Miki
2010/7/10 Miki Tebeka <miki.tebeka@gmail.com>:
Hello Tal,
I would like to propose removing IDLE from the standard library. -1. One of the biggest "selling points" for me when switching to python was the "out of the box" working IDE with REPL, syntax highliting and a debugger. The only other candidate I think of to replace IDLE might be IPython. However for novice users who are not used to command line it might be too intimidating.
There are my others IDEs out there, some better some worse. However IMO to have one bundled with Python is highly important.
Cross-platform support has degraded with the increasing popularity of OSX and 64-bit platforms. I use IDLE on Ubuntu 64bit and before that on OS X 64 bit, never had a problem. Can you give some examples on what do you mean by "cross-platform support"?
By "never had a problem" do you mean using some of the latest versions ? Here, running "idle" from a mac terminal and trying to type: print "hi" crashes when entering the quotation mark. I'm mostly sure this has been fixed on versions newer than 2.6.1 (but I hope you agree with me that shouldn't happen with a version distributed on macosx), so my another example is in the form of a question: how functional is the current IDLE debugger when running on a Mac ? -- -- Guilherme H. Polo Goncalves
On Jul 10, 2010, at 9:23 PM, Guilherme Polo wrote:
2010/7/10 Miki Tebeka <miki.tebeka@gmail.com>:
Hello Tal,
I would like to propose removing IDLE from the standard library. -1.
-1 from me too. IDLE is the tool I almost always used to introduce people to Python. FWIW, I've run in on a Mac and Windows without problems. Raymond
On Sat, Jul 10, 2010 at 9:23 PM, Guilherme Polo <ggpolo@gmail.com> wrote:
By "never had a problem" do you mean using some of the latest versions ? Here, running "idle" from a mac terminal and trying to type: print "hi" crashes when entering the quotation mark.
From the lurking crowd-- Please don't consider removing IDLE until there is a compelling replacement ready. It's better to have a limited IDE that works everywhere (even if in a limited fashion-- people are free to try out one of
Huh? Works fine for me. Python 2.6.1, OSX 10.6.3, intel. the many excellent full-featured Python IDE's out there after they advance to that point) then not. --Stephen
Stephen Hansen wrote:
On Sat, Jul 10, 2010 at 9:23 PM, Guilherme Polo <ggpolo@gmail.com <mailto:ggpolo@gmail.com>> wrote:
By "never had a problem" do you mean using some of the latest versions ? Here, running "idle" from a mac terminal and trying to type: print "hi" crashes when entering the quotation mark.
Huh? Works fine for me. Python 2.6.1, OSX 10.6.3, intel.
One of the good things about the python-dev community is its commitment to test-driven development. If you are prepared to define "fine" as 'successfully runs \'print "hello"\'' then I guess we should be perfectly happy about IDLE.
From the lurking crowd-- Please don't consider removing IDLE until there is a compelling replacement ready. It's better to have a limited IDE that works everywhere (even if in a limited fashion-- people are free to try out one of the many excellent full-featured Python IDE's out there after they advance to that point) then not.
1: I refuse to see why we need a "compelling replacement" for a piece of software whose performance might be actively deterring people from taking up the language. ["Have you thought about Python?" "Yeah, but I tried it {meaning "I downloaded some random Python release and tried IDLE, which by modern standards appears completely lame"} and it sucked". If this is our standard for "compelling" then it appears the command-line interpreter is the competition. 2: Correct me if I am wrong, but isn't the implied promise of including something in the stdlib that there will be active maintainers? If that's the case then we need to either recruit more active maintainers than the package currently has or look at dropping it. 3: If IDLE *is* going to be dropped from the stdlib it should be deprecated first just like anything else. 4: It's all very well chastising "the development community" because IDLE issues get assigned to kbk and nothing happens about them, but it's not like kbk is receiving any kind of rewards for working on these tickets, and precious little indication that anyone else is prepared to roll up their sleeves and ask to take over the tickets [apologies to anyone who has actually done this and been rebuffed] to get them fixed quicker. 5: Decide for yourself whether I am one of "the lurking crowd". I teach Python classes for a living (among other things) and invest quite a bit of time in the Python community one way or the other. I am not a Mac user, but another instructor I have employed is, and he has discussed with Mac users exactly how deficient the IDLE environment is when compared with standard Mac utilities. 6: When I give students a free choice of the development environment, they often choose IDLE "because it comes with Python". This usually results in a certain amount of discussion and comparison with tools like Wing, PythonWin and so on. Which in itself isn't a bad thing, but IDLE complares so badly with the other products that I sometimes feel Python suffers by association. IDLE has simplicity on its side, but every way it interacts with the user appears to be non-standard for most platforms. It needs some maintenance, but I don't see where that's going to come from. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 DjangoCon US September 7-9, 2010 http://djangocon.us/ See Python Video! http://python.mirocommunity.org/ Holden Web LLC http://www.holdenweb.com/
On Sun, Jul 11, 2010 at 4:53 PM, Steve Holden <steve@holdenweb.com> wrote:
Stephen Hansen wrote:
On Sat, Jul 10, 2010 at 9:23 PM, Guilherme Polo <ggpolo@gmail.com <mailto:ggpolo@gmail.com>> wrote:
By "never had a problem" do you mean using some of the latest versions ? Here, running "idle" from a mac terminal and trying to type: print "hi" crashes when entering the quotation mark.
Huh? Works fine for me. Python 2.6.1, OSX 10.6.3, intel.
One of the good things about the python-dev community is its commitment to test-driven development. If you are prepared to define "fine" as 'successfully runs \'print "hello"\'' then I guess we should be perfectly happy about IDLE.
Er, how hostile. My point is, the poster made an assertion-- that you couldn't do the simple act as launching idle from a command line, and printing Hi. Maybe they can't, I have no idea. I know I can. I know that I have also opened random python files, saved them, and ran them with IDLE. I don't use IDLE beyond that though: I live in TextMate on my mac. My point was not, "IDLE is perfect". My point was, "You've claimed you can't even print out a word in IDLE, so its utterly and completely non-functional" -- and that assertion surprises me and I challenge. I don't define IDLE as "fine", because I'm not qualified to speak to its larger aspects-- as I only rarely use it. But the level of utter brokenness that the poster I was replying to spoke of, I've never seen. Across multiple versions of Python, IDLE, and OSX.
From the lurking crowd-- Please don't consider removing IDLE until there
is a compelling replacement ready. It's better to have a limited IDE that works everywhere (even if in a limited fashion-- people are free to try out one of the many excellent full-featured Python IDE's out there after they advance to that point) then not.
1: I refuse to see why we need a "compelling replacement" for a piece of software whose performance might be actively deterring people from taking up the language. ["Have you thought about Python?" "Yeah, but I tried it {meaning "I downloaded some random Python release and tried IDLE, which by modern standards appears completely lame"} and it sucked". If this is our standard for "compelling" then it appears the command-line interpreter is the competition.
The claim that IDLE is "actively deterring" people from taking up Python is in my opinion unsupported. I know a lot of people who have and do use it, and I am personally (in my own experience) unaware of anyone who is actively deterred from using Python because of it. Therefore, I see no negative, and only a positive of IDLE's presence-- and so I'd want a compelling replacement available before that positive was wiped out. Perhaps your experience is different. So be it: but -- uh, really, Hostile. I was just sharing my own experience with using and talking to people who use IDLE. I've found it -- on the mac, but on other platforms as well -- an adequate but limited sort of IDE. I've found more issues with it with the people I know who use windows then mac (in particular, details of when the subprocess runs). But my comment was simply: it has constantly worked for me in the limited use I make of it, and I have a positive experience with the people I know that have used it. If your experience is different, that's fine. Perhaps your experience is more broad, more compelling, and representative of more people. But I, personally, would consider it a significant loss if IDLE went the way of the dodo or a third-party module. -- Stephen
-On [20100712 08:26], Stephen Hansen (apt.shansen@gmail.com) wrote:
But I, personally, would consider it a significant loss if IDLE went the way of the dodo or a third-party module.
Why would it be a significant loss if it went the way of a third party module? Clearly right now it's not being maintained as well as the rest of Python. Maybe that's a clear indicator that it's better maintained externally instead of in the main tree. And for what it is worth, I personally never used it beyond one time looking at it in disgust and neither do I know Pythonistas around me that use it. Bpython and ipython do get installed a lot though, even on Windows. And all these people, no matter their proficiency in programming, use an editor or IDE of some sort, but not IDLE. So I would not mourn to see IDLE get moved out of the main repository as I do not see the added value or benefit, not even for training (and since you're going to set up a training environment anyway, it can only be described as lazy if you are adamant on having it included in the base distribution). Just my EUR 0,02. -- Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org> / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B Born from the Dark, in the black Cloak of Night...
Am 12.07.2010 10:06, schrieb Jeroen Ruigrok van der Werven:
-On [20100712 08:26], Stephen Hansen (apt.shansen@gmail.com) wrote:
But I, personally, would consider it a significant loss if IDLE went the way of the dodo or a third-party module.
Why would it be a significant loss if it went the way of a third party module? Clearly right now it's not being maintained as well as the rest of Python.
I start disagreeing here already. It *is* as well maintained as the rest of Python - at least, there are many other parts of Python that get the same attention (or less). IDLE has been working for years, in a certain feature set. It just doesn't need much "maintenance", except for updates when the world around it is changing.
Maybe that's a clear indicator that it's better maintained externally instead of in the main tree.
That's an unfounded theory, at best. Two experiments to pro
So I would not mourn to see IDLE get moved out of the main repository as I do not see the added value or benefit
Now that's a different issue. You are not using it, fine. Does that mean it should be removed? If we removed all modules that somebody is not using, the standard library would be empty. Regards, Martin
On Mon, Jul 12 2010, Jeroen Ruigrok van der Werven wrote:
-On [20100712 08:26], Stephen Hansen (apt.shansen@gmail.com) wrote:
But I, personally, would consider it a significant loss if IDLE went the way of the dodo or a third-party module.
Why would it be a significant loss if it went the way of a third party module? Clearly right now it's not being maintained as well as the rest of Python. Maybe that's a clear indicator that it's better maintained externally instead of in the main tree.
And for what it is worth, I personally never used it beyond one time looking at it in disgust
Apparently you haven't looked recently. If you'd describe specifically what is disgusting on the current version, perhaps we can do something about it.
and neither do I know Pythonistas around me that use it. Bpython and ipython do get installed a lot though, even on Windows. And all these people, no matter their proficiency in programming, use an editor or IDE of some sort, but not IDLE.
Well, I use it :-) I used to use emacs to develop IDLE, but as IDLE became more capable, I stopped using emacs (except to fix IDLE when I break it completely :) When I find something I really miss, I add it. But I don't just add features to check off a list. Search on the status bar and jump to definition are next.
So I would not mourn to see IDLE get moved out of the main repository as I do not see the added value or benefit, not even for training (and since you're going to set up a training environment anyway, it can only be described as lazy if you are adamant on having it included in the base distribution).
On Windows, IDLE opens when you right click / edit a .py. Very useful. On linux, the packagers generally split IDLE off into a separate package so Python can be installed without Tcl/Tk. That doesn't mean it should be removed from the tarball; their package build tools build several packages from the single tarball at the same time. Second guessing them by having two tarballs just increases the work for everyone. This could be done on Windows, but then you wouldn't have a GUI to use right after running the Python installer. Minimal installations are not so important on Windows. -- KBK
On 7/12/2010 5:46 AM, Kurt B. Kaiser wrote:
On Windows, IDLE opens when you right click / edit a .py. Very useful.
On my xp machine with 3.1.2, it edit .py opens with notepad. Perhaps the installer just copies forward the association from long ago, before IDLE was available, or at least so usable. I have thought of changing that, but I do not know what the replacement incantation would be. -- Terry Jan Reedy
Am 12.07.2010 23:21, schrieb Terry Reedy:
On 7/12/2010 5:46 AM, Kurt B. Kaiser wrote:
On Windows, IDLE opens when you right click / edit a .py. Very useful.
On my xp machine with 3.1.2, it edit .py opens with notepad. Perhaps the installer just copies forward the association from long ago, before IDLE was available, or at least so usable. I have thought of changing that, but I do not know what the replacement incantation would be.
There should be an "Edit with IDLE" (sic) context menu item. Regards, Martin
On 7/12/2010 5:43 PM, "Martin v. Löwis" wrote:
Am 12.07.2010 23:21, schrieb Terry Reedy:
On 7/12/2010 5:46 AM, Kurt B. Kaiser wrote:
On Windows, IDLE opens when you right click / edit a .py. Very useful.
On my xp machine with 3.1.2, it edit .py opens with notepad. Perhaps the installer just copies forward the association from long ago, before IDLE was available, or at least so usable. I have thought of changing that, but I do not know what the replacement incantation would be.
There should be an "Edit with IDLE" (sic) context menu item.
I agree, and thought about requesting such, but there is not and never has been for me that I know of. Actually, I would like Edit with IDLE x.y and Run with x.y so it is easy to test a file with different versions. XP with updates, install for everyone, make install the default Python. Should I open a tracker issue? -- Terry Jan Reedy
On 12/07/2010 23:00, Terry Reedy wrote:
On 7/12/2010 5:43 PM, "Martin v. Löwis" wrote:
Am 12.07.2010 23:21, schrieb Terry Reedy:
On 7/12/2010 5:46 AM, Kurt B. Kaiser wrote:
On Windows, IDLE opens when you right click / edit a .py. Very useful.
On my xp machine with 3.1.2, it edit .py opens with notepad. Perhaps the installer just copies forward the association from long ago, before IDLE was available, or at least so usable. I have thought of changing that, but I do not know what the replacement incantation would be.
There should be an "Edit with IDLE" (sic) context menu item.
I agree, and thought about requesting such, but there is not and never has been for me that I know of. Actually, I would like Edit with IDLE x.y and Run with x.y so it is easy to test a file with different versions.
I have "Edit with IDLE" as a context menu option for Windows 7 - so it does exist *sometimes*. Either an XP issue or a "your system" issue I guess. Michael
XP with updates, install for everyone, make install the default Python.
Should I open a tracker issue?
-- 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 12 July 2010 23:00, Terry Reedy <tjreedy@udel.edu> wrote:
On 7/12/2010 5:43 PM, "Martin v. Löwis" wrote:
There should be an "Edit with IDLE" (sic) context menu item.
I agree, and thought about requesting such, but there is not and never has been for me that I know of.
There is for me. I think what Martin meant was that the standard install puts one there, and if you don't have one it looks like your install is broken somehow.
Actually, I would like Edit with IDLE x.y and Run with x.y so it is easy to test a file with different versions.
I'm not sure I would, too much menu clutter. But as an install-time option I'd be OK with it.
XP with updates, install for everyone, make install the default Python.
Should I open a tracker issue?
If you can reproduce it, I guess so. But as I say, I have the entry (Win7, 2.6.3, install for everyone, default Python). So it's not a universal issue. Paul.
Am 13.07.2010 00:00, schrieb Terry Reedy:
On 7/12/2010 5:43 PM, "Martin v. Löwis" wrote:
Am 12.07.2010 23:21, schrieb Terry Reedy:
On 7/12/2010 5:46 AM, Kurt B. Kaiser wrote:
On Windows, IDLE opens when you right click / edit a .py. Very useful.
On my xp machine with 3.1.2, it edit .py opens with notepad. Perhaps the installer just copies forward the association from long ago, before IDLE was available, or at least so usable. I have thought of changing that, but I do not know what the replacement incantation would be.
There should be an "Edit with IDLE" (sic) context menu item.
I agree, and thought about requesting such
You misunderstand. There should be such a menu item *today*, *on your machine*. If it's not there, either the installation procedure went wrong, or you opted out of having it.
Should I open a tracker issue?
Please, no. Regards, Martin
On 7/12/2010 6:50 PM, "Martin v. Löwis" wrote:
Am 13.07.2010 00:00, schrieb Terry Reedy:
On 7/12/2010 5:43 PM, "Martin v. Löwis" wrote:
There should be an "Edit with IDLE" (sic) context menu item.
I agree, and thought about requesting such
You misunderstand.
To the contrary. You misunderstood my humor ;-).
There should be such a menu item *today*, *on your machine*.
Yes, I understood that claim.
If it's not there, either the installation procedure went wrong,
It has never indicated that there was a problem.
or you opted out of having it.
I do not recall having ever seen an option to include or exclude 'Edit with IDLE'. I will check more carefully on my next install. I still wonder whether the installer is paying too much attention in this regard to the previous install. One thing it does not do, however, is pay enough attention to where the current install is. If I already have /xxx/python31, then it should at least default to putting a bugfix releases in the same place. -- Terry Jan Reedy
On Mon, Jul 12 2010, Terry Reedy wrote:
On 7/12/2010 5:43 PM, "Martin v. Löwis" wrote:
Am 12.07.2010 23:21, schrieb Terry Reedy:
On 7/12/2010 5:46 AM, Kurt B. Kaiser wrote:
On Windows, IDLE opens when you right click / edit a .py. Very useful.
On my xp machine with 3.1.2, it edit .py opens with notepad. Perhaps the installer just copies forward the association from long ago, before IDLE was available, or at least so usable. I have thought of changing that, but I do not know what the replacement incantation would be.
There should be an "Edit with IDLE" (sic) context menu item.
I agree, and thought about requesting such, but there is not and never has been for me that I know of. Actually, I would like Edit with IDLE x.y and Run with x.y so it is easy to test a file with different versions.
XP with updates, install for everyone, make install the default Python.
It should be the second item on the right click context menu when hovering over a .py. If not, check your Windows Explorer / Tools / Folder Options / File Types / Advanced. There should be an "Edit with IDLE" in the dialog selection box. Perhaps you overrode it at some point. I've found that whatever version of IDLE is installed last grabs this function. If you build from svn, you don't get it, of course, unless you set it manually. And, you can use the manual setting to select a specific Python/IDLE version.
Should I open a tracker issue?
No, it's your system configuration, 99% probable. -- KBK
Stephen Hansen <apt.shansen@gmail.com> wrote:
On Sun, Jul 11, 2010 at 4:53 PM, Steve Holden <steve@holdenweb.com> wrote:
Stephen Hansen wrote:
On Sat, Jul 10, 2010 at 9:23 PM, Guilherme Polo <ggpolo@gmail.com <mailto:ggpolo@gmail.com>> wrote:
By "never had a problem" do you mean using some of the latest versions ? Here, running "idle" from a mac terminal and trying to type: print "hi" crashes when entering the quotation mark.
Huh? Works fine for me. Python 2.6.1, OSX 10.6.3, intel.
One of the good things about the python-dev community is its commitment to test-driven development. If you are prepared to define "fine" as 'successfully runs \'print "hello"\'' then I guess we should be perfectly happy about IDLE.
Er, how hostile.
My point is, the poster made an assertion-- that you couldn't do the simple act as launching idle from a command line, and printing Hi. Maybe they can't, I have no idea.
I know I can. I know that I have also opened random python files, saved them, and ran them with IDLE. I don't use IDLE beyond that though: I live in TextMate on my mac.
My point was not, "IDLE is perfect". My point was, "You've claimed you can't even print out a word in IDLE, so its utterly and completely non-functional" -- and that assertion surprises me and I challenge.
Steve, you encouraged me to try it again. From an xterm on OS X 10.5.8, it launches fine (long as you know where it is -- /System/Library/Frameworks/Python.framework/Versions/Current/bin/idle). Seems to work OK for what it is, too. Same for Terminal. When I start it from the *shell* buffer in Cocoa GNU Emacs, though, the idle window pops up under the Emacs window, which is why I didn't see it over the weekend. Bill
On 11 Jul, 2010, at 6:23, Guilherme Polo wrote:
2010/7/10 Miki Tebeka <miki.tebeka@gmail.com>:
Hello Tal,
I would like to propose removing IDLE from the standard library. -1. One of the biggest "selling points" for me when switching to python was the "out of the box" working IDE with REPL, syntax highliting and a debugger. The only other candidate I think of to replace IDLE might be IPython. However for novice users who are not used to command line it might be too intimidating.
There are my others IDEs out there, some better some worse. However IMO to have one bundled with Python is highly important.
Cross-platform support has degraded with the increasing popularity of OSX and 64-bit platforms. I use IDLE on Ubuntu 64bit and before that on OS X 64 bit, never had a problem. Can you give some examples on what do you mean by "cross-platform support"?
By "never had a problem" do you mean using some of the latest versions ? Here, running "idle" from a mac terminal and trying to type: print "hi" crashes when entering the quotation mark. I'm mostly sure this has been fixed on versions newer than 2.6.1 (but I hope you agree with me that shouldn't happen with a version distributed on macosx), so my another example is in the form of a question: how functional is the current IDLE debugger when running on a Mac ?
Apple basicly ships whatever is available at a cutoff point in their release cycle, without much if any involvment of the python-dev community. Have you tested this behaviour with a newer release of IDLE (the current 2.6.x release and the 2.7 release)? Does the IDLE application work for you (in "/Applications/Python X.Y" if you installed using a python.org binary installer)? And most importantly: have you filed bugs about things that don't work for you? If you don't file bugs there is little chance that issues get fixed unless some core developer happens to run into the same issue while having time to work on it. W.r.t. your last question: I don't know, I don't use IDLE or its debugger myself. Ronald
On 11 Jul, 2010, at 1:05, Tal Einat wrote:
Hello,
I would like to propose removing IDLE from the standard library.
I have been using IDLE since 2002 and have been doing my best to help maintain and further develop IDLE since 2005.
In recent years IDLE has received negligible interest and attention from the Python community. During this time IDLE has slowly gone downhill. The documentation and tutorials grow increasingly out of date. Cross-platform support has degraded with the increasing popularity of OSX and 64-bit platforms. Bugs take months, and sometimes more than a year, to be solved. Features that have since become common-place, such as having a non-intrusive search box instead of a dialog, are obviously and painfully lacking, making IDLE feel clumsy and out-dated.
Are their patches that fixes these problems? If not, are their at least issues on python's tracker?
For these reasons, I think it would be fitting to remove IDLE from the standard library. IDLE is no longer recommended to beginners, IMO rightfully so, and this was the main reason for its inclusion in the standard library. Furthermore, if there is little or no interest in developing and maintaining IDLE, it should be removed to avoid having buggy and badly supported software in the standard library.
I'm -1 on that. Several books, including fairly recent ones, use IDLE as the IDE for running examples. Ronald
On 2010-07-11, Ronald Oussoren wrote:
On 11 Jul, 2010, at 1:05, Tal Einat wrote:
Hello,
I would like to propose removing IDLE from the standard library.
-1
I have been using IDLE since 2002 and have been doing my best to help maintain and further develop IDLE since 2005. [snip]
I'm -1 on that. Several books, including fairly recent ones, use IDLE as the IDE for running examples.
Ronald
Thanks for mentioning that! My book "Programming in Python 3 (second edition)" introduces IDLE in Chapter 1 as follows: "As the screenshot in Figure 1.1 shows, IDLE has a rather retro look that harks back to the days of Motif on Unix and Windows 95. This is because it uses the Tk-based Tkinter GUI library (covered in Chapter 15) rather than one of the more powerful modern GUI libraries such as PyGtk, PyQt, or wxPython. The reasons for the use of Tkinter are a mixture of history, liberal license conditions, and the fact that Tkinter is much smaller than the other GUI libraries. On the plus side, IDLE comes as standard with Python and is very simple to learn and use." I personally really dislike Tcl/Tk. Nonetheless I invariably prefer to use IDLE than the raw command line for experimenting with Python and also for doing small one off custom jobs, so I end up using IDLE most days. I use IDLE on Linux & Windows (both 32 bit) with no problems. (My usage is purely of the interactive shell, I never use IDLE for editing.) -- Mark Summerfield, Qtrac Ltd, www.qtrac.eu C++, Python, Qt, PyQt - training and consultancy "Programming in Python 3" - ISBN 0321680561 http://www.qtrac.eu/py3book.html
I would like to propose removing IDLE from the standard library.
I have been using IDLE since 2002 and have been doing my best to help maintain and further develop IDLE since 2005.
I'm surprised by the amount of interest this has raised already. To answer a few questions that were raised: In recent years I have worked up many patches, both bugfixes and new features and improvements. Getting any attention to these was non-trivial, and getting patches accepted (or an explanation why they are rejected in some cases) almost always took many months, sometimes years, and some are still unresolved. It has been very frustrating. When I ran into bugs I fixed them and submitted a patch. I have also done so for quite a few bugs reported by others. However, there are currently several bugs in the tracker which nobody is taking any notice of. IIRC most of the recent bugs are related to OSX or 64-bit Windows. To those who mention that IDLE is "okay" or "not going uphill", my grandfather would say "if you aren't running forwards, you are falling behind." You should know how IDLE looks to programmers seeing it for the first time -- IDLE's quirky and old-fashioned looks and interface are a major turnoff for new users. As a result I have stopped recommending it to coworkers, despite personally liking IDLE, instead recommending the basic command-line or IPython for interactive work, and any other IDE or text editor for development. I too prefer IDLE to the basic command line, and think that something like IDLE is well-suited for learning/teaching Python. I also think an interpreter with a nice GUI can be far superior to a text-only interpreter. However, I've mostly lost hope for IDLE, and am currently hoping that something else takes its place. The fact is that for many years little effort has gone into developing and maintaining IDLE, and I believe being tucked in a corner of the Python codebase is a major reason for this. I really don't see why IDLE has to be part of the standard library, what's wrong with IDLE being an externally maintained application? Yes, IDLE still works (mostly), but us few who continue to use it could do so even if it weren't part of the standard library. - Tal Einat
On 11 Jul, 2010, at 10:57, Tal Einat wrote:
When I ran into bugs I fixed them and submitted a patch. I have also done so for quite a few bugs reported by others. However, there are currently several bugs in the tracker which nobody is taking any notice of. IIRC most of the recent bugs are related to OSX or 64-bit Windows.
The OSX issues al seem to be related to general Tk or Tkinter bugs on OSX. I know to little about Tk and Tkinter to seriously work on those. Ronald
On Sun, Jul 11, 2010 at 12:03 PM, Ronald Oussoren wrote:
On 11 Jul, 2010, at 10:57, Tal Einat wrote:
When I ran into bugs I fixed them and submitted a patch. I have also done so for quite a few bugs reported by others. However, there are currently several bugs in the tracker which nobody is taking any notice of. IIRC most of the recent bugs are related to OSX or 64-bit Windows.
The OSX issues al seem to be related to general Tk or Tkinter bugs on OSX. I know to little about Tk and Tkinter to seriously work on those.
Ronald
Perhaps, but the point is that these bugs remain. Certainly this isn't because just you, out of the entire Python development community, know little about Tk and Tkinter. Using Tkinter is a major reason that maintaining and further developing IDLE is difficult. For example, it took me many hours just to get a working Tkinter scrolled frame widget, having had to write it from scratch and struggle with the under-documented Canvas widget. Another example is that integration of the new ttk (a.k.a. Tile) widget set, which supports native look&feel on various platforms and adds modern widgets, has still not been integrated despite being available in Tk for years and despite considerable effort being invested into it. - Tal Einat
On 7/11/10 5:03 AM, Ronald Oussoren wrote:
The OSX issues al seem to be related to general Tk or Tkinter bugs on OSX. I know to little about Tk and Tkinter to seriously work on those.
Ronald, How about http://bugs.python.org/issue6075? I first submitted that patch in May '09, and updated it in October '09 on request from you, and it's just sat there since... --Kevin -- Kevin Walzer Code by Kevin http://www.codebykevin.com
On 11 Jul, 2010, at 15:24, Kevin Walzer wrote:
On 7/11/10 5:03 AM, Ronald Oussoren wrote:
The OSX issues al seem to be related to general Tk or Tkinter bugs on OSX. I know to little about Tk and Tkinter to seriously work on those.
Ronald,
How about http://bugs.python.org/issue6075? I first submitted that patch in May '09, and updated it in October '09 on request from you, and it's just sat there since...
If I read the patch correctly it replaces the existing 8.4 support by support for 8.5. That would not be acceptable because it would result in a non-functional version of IDLE for anyone that hasn't installed a custom copy of Tk. The "checkForAppKit" function doesn't work with the system version of Tk that Python currently links to. Does the patch work with the system version of Tk 8.4 on OSX? Ronald
--Kevin
-- Kevin Walzer Code by Kevin http://www.codebykevin.com
If I read the patch correctly it replaces the existing 8.4 support by support for 8.5. That would not be acceptable because it would result in a non-functional version of IDLE for anyone that hasn't installed a custom copy of Tk.
Not quite. It doesn't specify a version of Tk to run; it checks instead for whether Tk is built on Cocoa or Carbon. (It needs 8.5 to run on Cocoa.)
The "checkForAppKit" function doesn't work with the system version of Tk that Python currently links to.
The checkForAppKit function queries the Tk windowing server for some information about its implementation. If it find 'AppKit,' then Cocoa's running: if no, then Carbon's running. If Carbon, then the code falls back to the current implementation.
Does the patch work with the system version of Tk 8.4 on OSX?
I just tested it against Python 2.5/Tk 8.4.7 (the system install on Leopard), which runs on Carobn, and it works fine. I've also tested it against 2.6 with Tk-Cocoa, and again it runs fine. I don't have access to other combinations of Python and Tk, such as Python 3.1, but I think these results indicate it's safe to apply. --Kevin -- Kevin Walzer Code by Kevin http://www.codebykevin.com
On Sun, Jul 11, 2010 at 11:57 AM, Tal Einat wrote:
I would like to propose removing IDLE from the standard library.
I have been using IDLE since 2002 and have been doing my best to help maintain and further develop IDLE since 2005.
I'm surprised by the amount of interest this has raised already. To answer a few questions that were raised:
To those who mention that IDLE is "okay" or "not going uphill", my grandfather would say "if you aren't running forwards, you are falling behind." You should know how IDLE looks to programmers seeing it for the first time -- IDLE's quirky and old-fashioned looks and interface are a major turnoff for new users. As a result I have stopped recommending it to coworkers, despite personally liking IDLE, instead recommending the basic command-line or IPython for interactive work, and any other IDE or text editor for development.
I too prefer IDLE to the basic command line, and think that something like IDLE is well-suited for learning/teaching Python. I also think an interpreter with a nice GUI can be far superior to a text-only interpreter. However, I've mostly lost hope for IDLE, and am currently hoping that something else takes its place.
The fact is that for many years little effort has gone into developing and maintaining IDLE, and I believe being tucked in a corner of the Python codebase is a major reason for this. I really don't see why IDLE has to be part of the standard library, what's wrong with IDLE being an externally maintained application?
Yes, IDLE still works (mostly), but us few who continue to use it could do so even if it weren't part of the standard library.
Most of the responses up to this point have been strongly against my proposal. The main reason given is that it is nice to have a graphical IDE supported out-of-the-box with almost any Python installation. This is especially important for novice programmers and in teaching environments. I understand this sentiment, but I think that supplying a quirky IDE with many caveats, lacking documentation, some bugs and a partially working debugger ends up causing more confusion than good. Initially (five years ago!) I tried to overcome these issues by improving IDLE, solving problems and adding a few key features. Without going into details, suffice to say that IDLE hasn't improved much since 2005 despite my efforts. For example, see http://bugs.python.org/issue1529142, where it took nearly 3 years to fix a major issue from the moment I posted the first workaround. For another example, see http://bugs.python.org/issue3068, where I posted a patch for an extension configuration dialog over two years ago, and it hasn't received as much as a sneeze in response. Although several people say that they think having IDLE in the stdlib is important, the fact is that IDLE is considered quite unimportant by most of the Python community. Having IDLE in the stdlib may be convenient for a few people, but most never use it and don't care about it. I think that in its current state, IDLE may still be helpful for learning Python, but it is more likely to drive away users who run into its various quirks and problems. And for experienced Python developers, very few actually use IDLE, and those who do could easily install it if it weren't part of the stdlib. - Tal Einat
Tal Einat <taleinat@gmail.com> wrote:
Although several people say that they think having IDLE in the stdlib is important, the fact is that IDLE is considered quite unimportant by most of the Python community. Having IDLE in the stdlib may be convenient for a few people, but most never use it and don't care about it. I think that in its current state, IDLE may still be helpful for learning Python, but it is more likely to drive away users who run into its various quirks and problems. And for experienced Python developers, very few actually use IDLE, and those who do could easily install it if it weren't part of the stdlib.
I agree with you on this, Tal. On OS X, this is particularly aggravating, as the Apple-supplied Python doesn't seem to include a working version, and installing MacPython leads to other problems (see, for instance, the thread at http://groups.google.com/group/nltk-users/browse_thread/thread/e14b647243ca5...). For David and other teachers, there are plenty of alternative IDEs, outlined at http://wiki.python.org/moin/IntegratedDevelopmentEnvironments. Bill
On 11 Jul, 2010, at 19:35, Bill Janssen wrote:
Tal Einat <taleinat@gmail.com> wrote:
Although several people say that they think having IDLE in the stdlib is important, the fact is that IDLE is considered quite unimportant by most of the Python community. Having IDLE in the stdlib may be convenient for a few people, but most never use it and don't care about it. I think that in its current state, IDLE may still be helpful for learning Python, but it is more likely to drive away users who run into its various quirks and problems. And for experienced Python developers, very few actually use IDLE, and those who do could easily install it if it weren't part of the stdlib.
I agree with you on this, Tal. On OS X, this is particularly aggravating, as the Apple-supplied Python doesn't seem to include a working version, and installing MacPython leads to other problems (see, for instance, the thread at http://groups.google.com/group/nltk-users/browse_thread/thread/e14b647243ca5...).
Apple doesn't ship IDLE.app, but does ship the rest of the code. It should be fairly easy to create a small IDLE.app using the python.org source tree that uses /usr/bin/python. Ronald
Initially (five years ago!) I tried to overcome these issues by improving IDLE, solving problems and adding a few key features. Without going into details, suffice to say that IDLE hasn't improved much since 2005 despite my efforts. For example, see http://bugs.python.org/issue1529142, where it took nearly 3 years to fix a major issue from the moment I posted the first workaround. For another example, see http://bugs.python.org/issue3068, where I posted a patch for an extension configuration dialog over two years ago, and it hasn't received as much as a sneeze in response.
I can understand that this is frustrating, but please understand that this is not specific to your patches, or to IDLE. Many other patches on bugs.python.org remain unreviewed for many years. That's because many of the issues are really tricky, and there are very few people who both have the time and the expertise to evaluate them. FWIW, I don't consider a few months as a "long" time for a patch review. At the moment, I'm personally able to perhaps review one issue per week (sometimes less); at this rate, it'll take several years until I get to everything. Regards, Martin
On Jul 11, 2010, at 2:37 PM, Martin v. Löwis wrote:
Initially (five years ago!) I tried to overcome these issues by improving IDLE, solving problems and adding a few key features. Without going into details, suffice to say that IDLE hasn't improved much since 2005 despite my efforts. For example, see http://bugs.python.org/issue1529142, where it took nearly 3 years to fix a major issue from the moment I posted the first workaround. For another example, see http://bugs.python.org/issue3068, where I posted a patch for an extension configuration dialog over two years ago, and it hasn't received as much as a sneeze in response.
I can understand that this is frustrating, but please understand that this is not specific to your patches, or to IDLE. Many other patches on bugs.python.org remain unreviewed for many years. That's because many of the issues are really tricky, and there are very few people who both have the time and the expertise to evaluate them.
This problem seems to me to be the root cause here. Guido proposes to give someone interested in IDLE commit access, and hopefully that will help in this particular area. But, as I recall, at the last language summit there was quite a bit of discussion about how to address the broader issue of patches falling into a black hole. Is anybody working on it? (This seems to me like an area where a judicious application of PSF funds might help; if every single bug were actively triaged and responded to, even if it weren't reviewed, and patch contributors were directed to take specific steps to elicit a response or a review, the fact that patch reviews take a while might not be so bad.)
FWIW, I don't consider a few months as a "long" time for a patch review.
It may not be a long time compared to other patch reviews, but it is a very long time for a volunteer to wait for something, especially if that "something" is "any indication that the python developers care that this patch was submitted at all". There seems to be at least one thread a month on this list from a disgruntled community member complaining (directly or indirectly) about this delay. I think that makes it a big problem.
At the moment, I'm personally able to perhaps review one issue per week (sometimes less); at this rate, it'll take several years until I get to everything.
I guess it depends what you mean by "everything", but given that the open bug count is actually increasing at a significant rate, I would say that you can never possibly get to "everything".
(This seems to me like an area where a judicious application of PSF funds might help; if every single bug were actively triaged and responded to, even if it weren't reviewed, and patch contributors were directed to take specific steps to elicit a response or a review, the fact that patch reviews take a while might not be so bad.)
I'm skeptical. The current triage process often results in assigning bugs to somebody, with the entirely unfounded expectation that somebody then will act on it - unfortunately, both the submitter and the triager seem to have that expectation. Unfortunately, it's often not clear what the submitter wants: does she want to help, or want to get help? For a bug report, I often post a message "can you provide a patch?", but sometimes, it isn't that clear.
At the moment, I'm personally able to perhaps review one issue per week (sometimes less); at this rate, it'll take several years until I get to everything.
I guess it depends what you mean by "everything", but given that the open bug count is actually /increasing/ at a significant rate, I would say that you can never possibly get to "everything".
Right, I was trying to put things positively :-) Regards, Martin
On Jul 11, 2010, at 3:19 PM, Martin v. Löwis wrote:
Unfortunately, it's often not clear what the submitter wants: does she want to help, or want to get help? For a bug report, I often post a message "can you provide a patch?", but sometimes, it isn't that clear.
Perhaps this is the one area where the biggest advance could be made: a clarification of the workflow. My experience with Python issues which have been "triaged" is that everyone who triages tickets has a slightly different idea of who is responsible for the ticket and what they're supposed to do next at every point in the process. Triage, as described on <http://www.python.org/dev/workflow/>, emphasizes making sure "that all fields in the issue tracker are properly set", rather than on communicating with the contributor or reporter. On Twisted, we try to encourage triagers to focus on communicating the workflow ramifications of what a particular contributor has done. We try to provide a response to the bug reporter or patch submitter that says "thanks, but in order to move this along, you need to go through the following steps" and sometimes even attach a link to the workflow document pointing out exactly where in the process the ticket is now stuck. (At least, that's what we're trying to do.) This involves a lot of repeating ourselves in ticket comments, but it's well worth it (and as more of the repetition moves into citing links to documents that have been written to describe aspects of the workflow, it's less onerous). <http://www.python.org/dev/workflow/> describes what the steps are, but it's in a sort of procedural passive voice that doesn't say who is responsible for doing reviews or how to get a list of patches which need to be reviewed or what exactly a third-party non-core-committer reviewer should do to remove the 'Patch review' keyword. <http://twistedmatrix.com/trac/wiki/TwistedDevelopment#SubmittingaPatch> and <http://twistedmatrix.com/trac/wiki/ReviewProcess> meander around a bit, but a while ago we re-worked them so that each section has a specific audience (authors, reviewers, or external patch submitters) and that helped readers understand what they're intended to do. Plus, <http://twistedmatrix.com/trac/report/15> is a useful resource for core developers with only a little bit of free time to do a review. (I'm just offering some suggestions based on what I think has worked, not to hold Twisted up as a paragon of a perfect streamlined process. We still have folks complain about stuck patches, these documents are _far_ from perfect, and there are still some varying opinions about how certain workflow problems should be dealt with and differences in quality of review. Plus, we have far fewer patches to deal with than Python. Nevertheless, the situation used to be worse for us, and these measures seem to have helped.)
On Sun, 11 Jul 2010 14:59:14 -0400 Glyph Lefkowitz <glyph@twistedmatrix.com> wrote:
Guido proposes to give someone interested in IDLE commit access, and hopefully that will help in > this particular area. But, as I recall, at the last language summit there was quite a bit of discussion about how to address the broader issue of patches falling into a black hole. Is anybody working on it?
I think the best way to "work on it" is to work on having more core developers, possibly with a more diverse range of interests.
(This seems to me like an area where a judicious application of PSF funds might help; if every single bug were actively triaged and responded to, even if it weren't reviewed, and patch contributors were directed to take specific steps to elicit a response or a review, the fact that patch reviews take a while might not be so bad.)
The operative word being "judicious". It is not obvious who should get funded, and for what tasks. Some specific issues (like email in 3.x) are large enough that they can be the sole focus of a fund grant. But I'm not sure triaging can apply. (besides, I am wary of making the job of interacting with our users and contributors a paid position, rather than a collective task.)
FWIW, I don't consider a few months as a "long" time for a patch review.
It may not be a long time compared to other patch reviews, but it is a very long time for a volunteer to wait for something, especially if that "something" is "any indication that the python developers care that this patch was submitted at all".
Agreed. Also, the later the response arrives, the likelier it is to be along the lines of “the patch doesn't apply cleanly anymore, can you write another one?”. Regards Antoine.
On Sun, Jul 11, 2010 at 3:38 PM, Antoine Pitrou <solipsis@pitrou.net> wrote:
On Sun, 11 Jul 2010 14:59:14 -0400 Glyph Lefkowitz <glyph@twistedmatrix.com> wrote:
Guido proposes to give someone interested in IDLE commit access, and hopefully that will help in > this particular area. But, as I recall, at the last language summit there was quite a bit of discussion about how to address the broader issue of patches falling into a black hole. Is anybody working on it?
I think the best way to "work on it" is to work on having more core developers, possibly with a more diverse range of interests.
(This seems to me like an area where a judicious application of PSF funds might help; if every single bug were actively triaged and responded to, even if it weren't reviewed, and patch contributors were directed to take specific steps to elicit a response or a review, the fact that patch reviews take a while might not be so bad.)
The operative word being "judicious". It is not obvious who should get funded, and for what tasks. Some specific issues (like email in 3.x) are large enough that they can be the sole focus of a fund grant. But I'm not sure triaging can apply.
I'm mulling over starting a monthly triage sprint under the auspices of Jesse Noeller's PSF sponsored sprints in the hopes of making this a little more fun. I'd appreciate comments on the idea. Geremy Condra
On Sun, Jul 11, 2010 at 8:22 PM, geremy condra <debatem1@gmail.com> wrote:
On Sun, Jul 11, 2010 at 3:38 PM, Antoine Pitrou <solipsis@pitrou.net> wrote:
On Sun, 11 Jul 2010 14:59:14 -0400 Glyph Lefkowitz <glyph@twistedmatrix.com> wrote:
Guido proposes to give someone interested in IDLE commit access, and hopefully that will help in > this particular area. But, as I recall, at the last language summit there was quite a bit of discussion about how to address the broader issue of patches falling into a black hole. Is anybody working on it?
I think the best way to "work on it" is to work on having more core developers, possibly with a more diverse range of interests.
(This seems to me like an area where a judicious application of PSF funds might help; if every single bug were actively triaged and responded to, even if it weren't reviewed, and patch contributors were directed to take specific steps to elicit a response or a review, the fact that patch reviews take a while might not be so bad.)
The operative word being "judicious". It is not obvious who should get funded, and for what tasks. Some specific issues (like email in 3.x) are large enough that they can be the sole focus of a fund grant. But I'm not sure triaging can apply.
I'm mulling over starting a monthly triage sprint under the auspices of Jesse Noeller's PSF sponsored sprints in the hopes of making this a little more fun. I'd appreciate comments on the idea.
Geremy Condra
Apologies, Jesse, I thought your name had an extra 'e' in it. Geremy Condra
On Sun, Jul 11, 2010 at 8:22 PM, geremy condra <debatem1@gmail.com> wrote:
On Sun, Jul 11, 2010 at 3:38 PM, Antoine Pitrou <solipsis@pitrou.net> wrote:
On Sun, 11 Jul 2010 14:59:14 -0400 Glyph Lefkowitz <glyph@twistedmatrix.com> wrote:
Guido proposes to give someone interested in IDLE commit access, and hopefully that will help in > this particular area. But, as I recall, at the last language summit there was quite a bit of discussion about how to address the broader issue of patches falling into a black hole. Is anybody working on it?
I think the best way to "work on it" is to work on having more core developers, possibly with a more diverse range of interests.
(This seems to me like an area where a judicious application of PSF funds might help; if every single bug were actively triaged and responded to, even if it weren't reviewed, and patch contributors were directed to take specific steps to elicit a response or a review, the fact that patch reviews take a while might not be so bad.)
The operative word being "judicious". It is not obvious who should get funded, and for what tasks. Some specific issues (like email in 3.x) are large enough that they can be the sole focus of a fund grant. But I'm not sure triaging can apply.
I'm mulling over starting a monthly triage sprint under the auspices of Jesse Noeller's PSF sponsored sprints in the hopes of making this a little more fun. I'd appreciate comments on the idea.
Geremy Condra
Well, I'd like to get the sprint "how to" docs in shape, and then yeah - we can totally do this. The sprints focuses were designed to help with this pain (as others have pointed out) as well as other pain points we've seen. Also note, hosting a "virtual sprint" or something like that, which the sponsored sprint group simply helps advertise and promote can help with this as well. It's important though, when looking at triaging to keep in mind: Moving the bug around (reassigning, etc) is of minimal use in a fair number of cases - now, making sure it has a reproducible test case (and can be reproduced), making sure the broken platforms are enumerated, that patches have tests and docs (and are based on the current trunk/whatever) and so on are much more valuable in the long run. Just some food for thought - and something to keep in mind if and when we get to document more of this/etc. jesse
Jesse Noller <jnoller@gmail.com> wrote:
On Sun, Jul 11, 2010 at 8:22 PM, geremy condra <debatem1@gmail.com> wrote:
(This seems to me like an area where a judicious application of PSF funds might help; if every single bug were actively triaged and responded to, even if it weren't reviewed, and patch contributors were directed to take specific steps to elicit a response or a review, the fact that patch reviews take a while might not be so bad.)
The operative word being "judicious". It is not obvious who should get funded, and for what tasks. Some specific issues (like email in 3.x) are large enough that they can be the sole focus of a fund grant. But I'm not sure triaging can apply.
I'm mulling over starting a monthly triage sprint under the auspices of Jesse Noeller's PSF sponsored sprints in the hopes of making this a little more fun. I'd appreciate comments on the idea.
[responding to Geremy] I'm with Georg on this. If triaging needs a monetary incentive because it is tedious work, so does committing. A lot of the abandoned issues aren't very glamorous either. Also, from the work that Mark Lawrence has been doing on the tracker in the past few weeks, it's apparent that a dedicated person can achieve a lot without pay. Due to his tracker reshuffling, many issues got closed, several bug reporters responded after years, etc. Thanks, Mark! Stefan Krah
On Mon, Jul 12, 2010 at 5:31 AM, Stefan Krah <stefan@bytereef.org> wrote:
Jesse Noller <jnoller@gmail.com> wrote:
On Sun, Jul 11, 2010 at 8:22 PM, geremy condra <debatem1@gmail.com> wrote:
(This seems to me like an area where a judicious application of PSF funds might help; if every single bug were actively triaged and responded to, even if it weren't reviewed, and patch contributors were directed to take specific steps to elicit a response or a review, the fact that patch reviews take a while might not be so bad.)
The operative word being "judicious". It is not obvious who should get funded, and for what tasks. Some specific issues (like email in 3.x) are large enough that they can be the sole focus of a fund grant. But I'm not sure triaging can apply.
I'm mulling over starting a monthly triage sprint under the auspices of Jesse Noeller's PSF sponsored sprints in the hopes of making this a little more fun. I'd appreciate comments on the idea.
[responding to Geremy]
I'm with Georg on this. If triaging needs a monetary incentive because it is tedious work, so does committing. A lot of the abandoned issues aren't very glamorous either.
I'm not sure what you mean by "monetary incentive". I was considering handing a t-shirt or beer token to the most productive sprinters, but that's about the limit of it, and I suspect that would come out of my pocket. I'd also emphasize that I am exactly as far as I stated on this: I'm mulling it over and asking for feedback. If it turns out that there are other things that python-dev feels are more necessary but similarly unglamorous, then I'll think about doing that instead.
Also, from the work that Mark Lawrence has been doing on the tracker in the past few weeks, it's apparent that a dedicated person can achieve a lot without pay.
Indeed, although I'm again unsure what pay has to do with this.
Due to his tracker reshuffling, many issues got closed, several bug reporters responded after years, etc. Thanks, Mark!
+1 Geremy Condra
geremy condra <debatem1@gmail.com> wrote:
On Mon, Jul 12, 2010 at 5:31 AM, Stefan Krah <stefan@bytereef.org> wrote:
Jesse Noller <jnoller@gmail.com> wrote:
On Sun, Jul 11, 2010 at 8:22 PM, geremy condra <debatem1@gmail.com> wrote:
(This seems to me like an area where a judicious application of PSF funds might help; if every single bug were actively triaged and responded to, even if it weren't reviewed, and patch contributors were directed to take specific steps to elicit a response or a review, the fact that patch reviews take a while might not be so bad.)
The operative word being "judicious". It is not obvious who should get funded, and for what tasks. Some specific issues (like email in 3.x) are large enough that they can be the sole focus of a fund grant. But I'm not sure triaging can apply.
I'm mulling over starting a monthly triage sprint under the auspices of Jesse Noeller's PSF sponsored sprints in the hopes of making this a little more fun. I'd appreciate comments on the idea.
[responding to Geremy]
I'm with Georg on this. If triaging needs a monetary incentive because it is tedious work, so does committing. A lot of the abandoned issues aren't very glamorous either.
I'm not sure what you mean by "monetary incentive". I was considering handing a t-shirt or beer token to the most productive sprinters, but that's about the limit of it, and I suspect that would come out of my pocket.
Sorry for misinterpreting your intentions. I was reading this in the context of "judicious application of PSF funds". What you are describing is of course quite judicious. To me, "PSF sponsored" sounded like there would be a lot more money involved. Stefan Krah
On Mon, Jul 12, 2010 at 7:17 AM, Stefan Krah <stefan@bytereef.org> wrote:
geremy condra <debatem1@gmail.com> wrote:
On Mon, Jul 12, 2010 at 5:31 AM, Stefan Krah <stefan@bytereef.org> wrote:
Jesse Noller <jnoller@gmail.com> wrote:
On Sun, Jul 11, 2010 at 8:22 PM, geremy condra <debatem1@gmail.com> wrote:
> (This seems to me like an area where a judicious application of PSF funds might help; if every > single bug were actively triaged and responded to, even if it weren't reviewed, and patch > contributors were directed to take specific steps to elicit a response or a review, the fact that > patch reviews take a while might not be so bad.)
The operative word being "judicious". It is not obvious who should get funded, and for what tasks. Some specific issues (like email in 3.x) are large enough that they can be the sole focus of a fund grant. But I'm not sure triaging can apply.
I'm mulling over starting a monthly triage sprint under the auspices of Jesse Noeller's PSF sponsored sprints in the hopes of making this a little more fun. I'd appreciate comments on the idea.
[responding to Geremy]
I'm with Georg on this. If triaging needs a monetary incentive because it is tedious work, so does committing. A lot of the abandoned issues aren't very glamorous either.
I'm not sure what you mean by "monetary incentive". I was considering handing a t-shirt or beer token to the most productive sprinters, but that's about the limit of it, and I suspect that would come out of my pocket.
Sorry for misinterpreting your intentions. I was reading this in the context of "judicious application of PSF funds". What you are describing is of course quite judicious.
To me, "PSF sponsored" sounded like there would be a lot more money involved.
Nope, as long as I can keep the costs under $100 or so (I'm the worlds biggest cheapskate, shouldn't be a problem) I doubt I'll ask for anything except that people promote and attend. Geremy Condra
On 12/07/2010 11:37, geremy condra wrote:
On Mon, Jul 12, 2010 at 5:31 AM, Stefan Krah<stefan@bytereef.org> wrote:
Jesse Noller<jnoller@gmail.com> wrote:
On Sun, Jul 11, 2010 at 8:22 PM, geremy condra<debatem1@gmail.com> wrote:
(This seems to me like an area where a judicious application of PSF funds might help; if every single bug were actively triaged and responded to, even if it weren't reviewed, and patch contributors were directed to take specific steps to elicit a response or a review, the fact that patch reviews take a while might not be so bad.)
The operative word being "judicious". It is not obvious who should get funded, and for what tasks. Some specific issues (like email in 3.x) are large enough that they can be the sole focus of a fund grant. But I'm not sure triaging can apply.
I'm mulling over starting a monthly triage sprint under the auspices of Jesse Noeller's PSF sponsored sprints in the hopes of making this a little more fun. I'd appreciate comments on the idea.
[responding to Geremy]
I'm with Georg on this. If triaging needs a monetary incentive because it is tedious work, so does committing. A lot of the abandoned issues aren't very glamorous either.
I'm not sure what you mean by "monetary incentive". I was considering handing a t-shirt or beer token to the most productive sprinters, but that's about the limit of it, and I suspect that would come out of my pocket. Any chance of getting me a t-shirt autographed by the one and only BDFL? :)
I'd also emphasize that I am exactly as far as I stated on this: I'm mulling it over and asking for feedback. If it turns out that there are other things that python-dev feels are more necessary but similarly unglamorous, then I'll think about doing that instead.
Also, from the work that Mark Lawrence has been doing on the tracker in the past few weeks, it's apparent that a dedicated person can achieve a lot without pay.
Indeed, although I'm again unsure what pay has to do with this.
Due to his tracker reshuffling, many issues got closed, several bug reporters responded after years, etc. Thanks, Mark!
+1
Geremy Condra
Geremy, Stefan, Jesse and anyone that I might have missed, thanks for your kind responses, its given me quite a lift. For the record note that I only got going because of a post on c.l.py from Terry Reedy, and that he too has been doing similar work on the issue tracker, my round Terry. :) Kindest regards. Mark Lawrence
On Sun, 11 Jul 2010 14:59:14 -0400, Glyph Lefkowitz <glyph@twistedmatrix.com> wrote:
On Jul 11, 2010, at 2:37 PM, Martin v. L=F6wis wrote:
I can understand that this is frustrating, but please understand that this is not specific to your patches, or to IDLE. Many other patches on bugs.python.org remain unreviewed for many years. That's because many of the issues are really tricky, and there are very few people who both have the time and the expertise to evaluate them.
This problem seems to me to be the root cause here.
Guido proposes to give someone interested in IDLE commit access, and hopefully that will help in this particular area. But, as I recall, at the last language summit there was quite a bit of discussion about how to address the broader issue of patches falling into a black hole. Is anybody working on it?
As Martin indicated, the biggest single problem is people hours, and the only way to address that is to get more people involved. Jesse has started the sprint sponsorship committee. Presumably at least some reviewed and committed core patches will come out of that, as well as hopefully raising the general activity level. Jesse's effort is already bearing fruit in that I think many more people are thinking about holding sprints than has been true in the past. ("Oh, you mean *I* could do that? Cool.") I and the other triage people have gotten some new triage people involved. We've also gotten some new committers. Ezio Melotti presented a talk on core development at the Italian Pycon, and will present it again at EuroPython. Brian Curtin did a presentation on bug fixing for the Chicago users group and has turned his presentation into documentation for the Sprint committee. Dan Buch will be giving a talk on Python development at PyOhio, and Catherin Devlin has set up other activities at aimed at introducing people to core development (her "teach me" session, and I'll be leading the core sprint after the con). Hopefully all of these activities will put some more people on track to helping out with issue review, patch development, and, eventually, becoming committers. So yes, things are being done. Anyone who wants to help out or has idea is, of course, welcome :)
(This seems to me like an area where a judicious application of PSF funds might help; if every single bug were actively triaged and responded to, even if it weren't reviewed, and patch contributors were directed to take specific steps to elicit a response or a review, the fact that patch reviews take a while might not be so bad.)
I scanned the commit log, and it looks to me like somewhere around 30 people have been active during the past month. That's not too bad, but each of us has specific areas of interest and limited time, and so bugs outside of those interest areas are more likely to get dropped on the floor. So, this is indeed an area where improvement is theoretically possible, but I'm not sure how we get from here to there. As you say, one option is for the PSF to fund people to do it somehow. (I'd be happy to be one of those people for some number of hours a week, by the way, but I doubt that the PSF budget is going to stretch to that kind of ongoing commitment.) But...if we had *enough* people volunteering, it would indeed be theoretically possible to consciously spread out the load so that issues get responded to in a timely fashion with constructive feedback. I'm not sure how we would structure this, but if someone steps forward to be organizer/driver, I bet we could come up with something. (Get lots of people to *sign up* for a one hour slot of triage work per week?) I don't think we have enough active volunteers now, but perhaps we can get there. It would also be great if every committer could find time to look at one bug *outside* of their main interest area for every N hours they spend on their interest area. (I try to do this, with varying degrees of success depending on the week.) -- R. David Murray www.bitdance.com
On Sun, Jul 11, 2010 at 13:30, R. David Murray <rdmurray@bitdance.com> wrote:
On Sun, 11 Jul 2010 14:59:14 -0400, Glyph Lefkowitz <glyph@twistedmatrix.com> wrote:
On Jul 11, 2010, at 2:37 PM, Martin v. L=F6wis wrote:
I can understand that this is frustrating, but please understand that this is not specific to your patches, or to IDLE. Many other patches on bugs.python.org remain unreviewed for many years. That's because many of the issues are really tricky, and there are very few people who both have the time and the expertise to evaluate them.
This problem seems to me to be the root cause here.
Guido proposes to give someone interested in IDLE commit access, and hopefully that will help in this particular area. But, as I recall, at the last language summit there was quite a bit of discussion about how to address the broader issue of patches falling into a black hole. Is anybody working on it?
As Martin indicated, the biggest single problem is people hours, and the only way to address that is to get more people involved.
Jesse has started the sprint sponsorship committee. Presumably at least some reviewed and committed core patches will come out of that, as well as hopefully raising the general activity level. Jesse's effort is already bearing fruit in that I think many more people are thinking about holding sprints than has been true in the past. ("Oh, you mean *I* could do that? Cool.")
I and the other triage people have gotten some new triage people involved. We've also gotten some new committers.
Ezio Melotti presented a talk on core development at the Italian Pycon, and will present it again at EuroPython. Brian Curtin did a presentation on bug fixing for the Chicago users group and has turned his presentation into documentation for the Sprint committee.
Dan Buch will be giving a talk on Python development at PyOhio, and Catherin Devlin has set up other activities at aimed at introducing people to core development (her "teach me" session, and I'll be leading the core sprint after the con).
Hopefully all of these activities will put some more people on track to helping out with issue review, patch development, and, eventually, becoming committers.
So yes, things are being done.
Anyone who wants to help out or has idea is, of course, welcome :)
(This seems to me like an area where a judicious application of PSF funds might help; if every single bug were actively triaged and responded to, even if it weren't reviewed, and patch contributors were directed to take specific steps to elicit a response or a review, the fact that patch reviews take a while might not be so bad.)
I scanned the commit log, and it looks to me like somewhere around 30 people have been active during the past month. That's not too bad, but each of us has specific areas of interest and limited time, and so bugs outside of those interest areas are more likely to get dropped on the floor.
So, this is indeed an area where improvement is theoretically possible, but I'm not sure how we get from here to there. As you say, one option is for the PSF to fund people to do it somehow. (I'd be happy to be one of those people for some number of hours a week, by the way, but I doubt that the PSF budget is going to stretch to that kind of ongoing commitment.)
I have a grant in to work on Python full-time for 2-3 months with one of the focus points being improving the developer docs. -Brett
But...if we had *enough* people volunteering, it would indeed be theoretically possible to consciously spread out the load so that issues get responded to in a timely fashion with constructive feedback. I'm not sure how we would structure this, but if someone steps forward to be organizer/driver, I bet we could come up with something. (Get lots of people to *sign up* for a one hour slot of triage work per week?) I don't think we have enough active volunteers now, but perhaps we can get there.
It would also be great if every committer could find time to look at one bug *outside* of their main interest area for every N hours they spend on their interest area. (I try to do this, with varying degrees of success depending on the week.)
-- 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/brett%40python.org
On Mon, Jul 12, 2010 at 6:30 AM, R. David Murray <rdmurray@bitdance.com> wrote:
So, this is indeed an area where improvement is theoretically possible, but I'm not sure how we get from here to there. As you say, one option is for the PSF to fund people to do it somehow. (I'd be happy to be one of those people for some number of hours a week, by the way, but I doubt that the PSF budget is going to stretch to that kind of ongoing commitment.)
One problem that can arise is that when the active maintainer for a particular area gets caught up in other things (e.g. KBK for Idle in this particular case - added directly to cc list), then the commit rate for that area drastically slows down. Other committers have become accustomed to deferring to the judgement of the active maintainer, so if that judgement isn't forthcoming, then things don't go in. As a community of volunteers, obviously the amount of time we can devote to Python varies based on other commitments. Perhaps we need to encourage active maintainers to be more proactive about identifying folks that regularly submit good patches that may be candidates for commit access in that area. Otherwise, when an active maintainer's time is taken up by other things there's an understandable reluctance to tread on an active maintainer's toes by bypassing them and giving the task to someone else. Not only that, but the current maintainer is usually in the best position to judge the quality of submitted patches, as they're the most familiar with the code in question. While there are many areas of the standard library that don't even have *one* designated maintainer at this point in time, our goal should probably be to try to reach the point of having at least two maintainers for each area so that one person getting busy doesn't halt progress. Regards, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
Am 11.07.2010 20:59, schrieb Glyph Lefkowitz:
On Jul 11, 2010, at 2:37 PM, Martin v. Löwis wrote:
Initially (five years ago!) I tried to overcome these issues by improving IDLE, solving problems and adding a few key features. Without going into details, suffice to say that IDLE hasn't improved much since 2005 despite my efforts. For example, see http://bugs.python.org/issue1529142, where it took nearly 3 years to fix a major issue from the moment I posted the first workaround. For another example, see http://bugs.python.org/issue3068, where I posted a patch for an extension configuration dialog over two years ago, and it hasn't received as much as a sneeze in response.
I can understand that this is frustrating, but please understand that this is not specific to your patches, or to IDLE. Many other patches on bugs.python.org <http://bugs.python.org> remain unreviewed for many years. That's because many of the issues are really tricky, and there are very few people who both have the time and the expertise to evaluate them.
This problem seems to me to be the root cause here.
Guido proposes to give someone interested in IDLE commit access, and hopefully that will help in this particular area. But, as I recall, at the last language summit there was quite a bit of discussion about how to address the broader issue of patches falling into a black hole. Is anybody working on it?
(This seems to me like an area where a judicious application of PSF funds might help; if every single bug were actively triaged and responded to, even if it weren't reviewed, and patch contributors were directed to take specific steps to elicit a response or a review, the fact that patch reviews take a while might not be so bad.)
Honestly, how would you feel as a committer to have scores of issues assigned to you -- as a consequence of speedy triage -- knowing that you have to invest potentially hours of volunteer time into them, while the person doing the triaging is done with the bug in a few minutes and paid for it? I'd feel a little bit duped. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.
On Jul 11, 2010, at 5:33 PM, Georg Brandl wrote:
Honestly, how would you feel as a committer to have scores of issues assigned to you -- as a consequence of speedy triage -- knowing that you have to invest potentially hours of volunteer time into them, while the person doing the triaging is done with the bug in a few minutes and paid for it? I'd feel a little bit duped.
That doesn't strike me as a particularly useful type of triage. The most useful type of triage in this case would be the kind where the bug gets re-assigned to the *original contributor*, not a core committer, with a message clearly saying "thanks! but we will not do anything further with this ticket until *you* do XYZ." This may result in some tickets getting left by wayside, but at least it will be clear that they have been left by the wayside, and whose responsibility they really are. Even so, I would certainly feel better having scores of issues assigned to me than I would feel having scores of issues that are just hanging out in limbo forever.
On 11/07/2010 19:59, Glyph Lefkowitz wrote:
On Jul 11, 2010, at 2:37 PM, Martin v. Löwis wrote:
Initially (five years ago!) I tried to overcome these issues by improving IDLE, solving problems and adding a few key features. Without going into details, suffice to say that IDLE hasn't improved much since 2005 despite my efforts. For example, see http://bugs.python.org/issue1529142, where it took nearly 3 years to fix a major issue from the moment I posted the first workaround. For another example, see http://bugs.python.org/issue3068, where I posted a patch for an extension configuration dialog over two years ago, and it hasn't received as much as a sneeze in response.
I can understand that this is frustrating, but please understand that this is not specific to your patches, or to IDLE. Many other patches on bugs.python.org remain unreviewed for many years. That's because many of the issues are really tricky, and there are very few people who both have the time and the expertise to evaluate them.
This problem seems to me to be the root cause here.
Guido proposes to give someone interested in IDLE commit access, and hopefully that will help in this particular area. But, as I recall, at the last language summit there was quite a bit of discussion about how to address the broader issue of patches falling into a black hole. Is anybody working on it?
(This seems to me like an area where a judicious application of PSF funds might help; if every single bug were actively triaged and responded to, even if it weren't reviewed, and patch contributors were directed to take specific steps to elicit a response or a review, the fact that patch reviews take a while might not be so bad.)
FWIW, I don't consider a few months as a "long" time for a patch review.
It may not be a long time compared to other patch reviews, but it is a very long time for a volunteer to wait for something, especially if that "something" is "any indication that the python developers care that this patch was submitted at all".
There seems to be at least one thread a month on this list from a disgruntled community member complaining (directly or indirectly) about this delay. I think that makes it a big problem.
At the moment, I'm personally able to perhaps review one issue per week (sometimes less); at this rate, it'll take several years until I get to everything.
I guess it depends what you mean by "everything", but given that the open bug count is actually increasing at a significant rate, I would say that you can never possibly get to "everything".
_______________________________________________ IDLE-dev mailing list IDLE-dev@python.org http://mail.python.org/mailman/listinfo/idle-dev
I have been attempting to fill this hole and have been faced with animosity from people who "hang out" on the python-dev IRC channel. I thought it was a complete and utter waste of space, so I don't intend going back. I would like things fixed, not a cosy little "who's round is it next" mentality from the triage team. IMHO if they spent more time doing things, and less time talking crap via IRC, things might get done. And before anyone says anything, I have been a former MBCS and CEng and only gave up cos I couldn't afford the annual fees cos of my health. Kindest regards. Mark Lawrence
2010/7/11 Mark Lawrence <breamoreboy@yahoo.co.uk>:
I have been attempting to fill this hole and have been faced with animosity from people who "hang out" on the python-dev IRC channel. I thought it was a complete and utter waste of space, so I don't intend going back. I would like things fixed, not a cosy little "who's round is it next" mentality from the triage team. IMHO if they spent more time doing things, and less time talking crap via IRC, things might get done. And before anyone says anything, I have been a former MBCS and CEng and only gave up cos I couldn't afford the annual fees cos of my health.
What exactly is the "who's round is it next" mentality? -- Regards, Benjamin
On Sun, 11 Jul 2010 23:51:35 +0100, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
I have been attempting to fill this hole and have been faced with animosity from people who "hang out" on the python-dev IRC channel. I thought it was a complete and utter waste of space, so I don't intend going back. I would like things fixed, not a cosy little "who's round is it next" mentality from the triage team. IMHO if they spent more
It was clear from a message you sent to me, that I didn't see until after your visit to the channel, that you don't have any experience on IRC. IRC is its own unique medium, with its own mores, conventions, and culture. That you perceived hostility was probably due to the nature of the medium and its communication via short sentences and intertwined conversations. And yes, the IRC channel is our "office water cooler" where we come to chat with each other about things unrelated to our coding work, as well as serious talk about the coding and bug triage work (some of which takes place *while* we're chatting about things like the World Cup Final). It's a community, and we hang out there because we find it fun to do so. We often tease each other mercilessly, and an outsider would probably wonder what the heck was going on if they didn't stick around long enough to get the flavor of the community. But we also do a lot of good communicating about bugs and code, helping each other to improve the quality of Python. I thought the conversation when you arrived was mostly positive, and we were trying to share our (somewhat disjointed, as we admitted) wisdom about what works best when doing triage. Antoine did lead off with a specific criticism, which was unfortunate and doubtless set a bad tone for you, and his mini-rant could have been more politely phrased given that you were a newcomer. But I use the term "mini-rant" descriptively...that is part of the IRC style of communication, for better or worse. As several people have pointed out, currently there is a dearth of good documentation about the Python workflow. I think Jesse's sprint effort is going to help improve this, and I know Brett Cannon really wants to have time to work the docs over thoroughly. But in the meantime, what we have is "institutional knowledge" locked up in people's heads. The python-dev mailing list is one way to get access to that knowledge, as is the tracker-discuss list for triage in particular...and the IRC channel is a great way to get access to that knowledge (like, for example, the fact that maintainers.rst is not out of date :), if you are comfortable with IRC style communication. If you don't find the IRC channel a useful place, there's no reason for you to hang out there. We were offering you the opportunity to experience the camaraderie and mutual help that we find there, and I'm very sorry that you instead found the experience offputting. It is not an exclusive club (far from it) and you would be welcome to return. As I also said to you in a private message, the non-exclusivity goes both ways...there is no *formal* "triage team", and only some of us who do triage work hang out on IRC, and only some of us who hang out on #python-dev do triage work. Further, many of the people who chat regularly on the IRC channel are committers, which is one of the reasons why it can be a rich resource while doing triage. Often enough, bugs get closed that way.[*] -- R. David Murray www.bitdance.com But, to be honest, I remember that Arfrever asked about committing the patch for a particular bug on at least three different days before someone finally had the time to do it. It was very appropriate for that bugfix to go in before the release, and he was very patient, and it did get done.
Am 12.07.2010 00:51, schrieb Mark Lawrence:
I have been attempting to fill this hole and have been faced with animosity from people who "hang out" on the python-dev IRC channel. I thought it was a complete and utter waste of space, so I don't intend going back.
I agree with everything David said about this. My personal opinion is that you've done great work on the tracker, and like a few others, I've "rediscovered" a few issues I wanted to fix thanks to your "stirring up the silt". I don't think you have reason to be offended by criticism (which was even pointed out to you as such). Try hanging around a little bit longer, take nothing too seriously, and see if you still get nothing of value from #python-dev.
I would like things fixed, not a cosy little "who's round is it next" mentality from the triage team. IMHO if they spent more time doing things, and less time talking crap via IRC, things might get done.
Sure, and if it was work time, we probably would do this ;). As it is right now, this is volunteer time, and I would say that we're entitled to do whatever helps us getting done the (not always exciting) work, and our IRC crap talk, if that's what it is, happens to be among that. cheers, Georg
Georg Brandl wrote:
Am 12.07.2010 00:51, schrieb Mark Lawrence:
I have been attempting to fill this hole and have been faced with animosity from people who "hang out" on the python-dev IRC channel. I thought it was a complete and utter waste of space, so I don't intend going back.
I agree with everything David said about this. My personal opinion is that you've done great work on the tracker, and like a few others, I've "rediscovered" a few issues I wanted to fix thanks to your "stirring up the silt". I don't think you have reason to be offended by criticism (which was even pointed out to you as such). Try hanging around a little bit longer, take nothing too seriously, and see if you still get nothing of value from #python-dev.
I would like things fixed, not a cosy little "who's round is it next" mentality from the triage team. IMHO if they spent more time doing things, and less time talking crap via IRC, things might get done.
Sure, and if it was work time, we probably would do this ;). As it is right now, this is volunteer time, and I would say that we're entitled to do whatever helps us getting done the (not always exciting) work, and our IRC crap talk, if that's what it is, happens to be among that.
I tend to agree with you, but the fact that it can deter stalwarts like Mark perhaps indicate that a little caution should be applied when dealing with newcomers or "outsiders". Without, I trust, spoiling the fun for the regulars. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 DjangoCon US September 7-9, 2010 http://djangocon.us/ See Python Video! http://python.mirocommunity.org/ Holden Web LLC http://www.holdenweb.com/
On 14/07/2010 09:10, Georg Brandl wrote:
Am 12.07.2010 00:51, schrieb Mark Lawrence:
I have been attempting to fill this hole and have been faced with animosity from people who "hang out" on the python-dev IRC channel. I thought it was a complete and utter waste of space, so I don't intend going back.
I agree with everything David said about this. My personal opinion is that you've done great work on the tracker, and like a few others, I've "rediscovered" a few issues I wanted to fix thanks to your "stirring up the silt". I don't think you have reason to be offended by criticism (which was even pointed out to you as such). Try hanging around a little bit longer, take nothing too seriously, and see if you still get nothing of value from #python-dev.
I would like things fixed, not a cosy little "who's round is it next" mentality from the triage team. IMHO if they spent more time doing things, and less time talking crap via IRC, things might get done.
Sure, and if it was work time, we probably would do this ;). As it is right now, this is volunteer time, and I would say that we're entitled to do whatever helps us getting done the (not always exciting) work, and our IRC crap talk, if that's what it is, happens to be among that.
cheers, Georg
Georg, Thanks to your response and the earlier one from David I now understand how things work. I'm actually on IRC right now. I consider this matter done and dusted, so let's move on shall we? Kindest regards. Mark Lawrence.
On 7/14/2010 4:10 AM, Georg Brandl wrote:
Sure, and if it was work time, we probably would do this ;). As it is right now, this is volunteer time, and I would say that we're entitled to do whatever helps us getting done the (not always exciting) work, and our IRC crap talk, if that's what it is, happens to be among that.
Aha! IRC ('chat') is like a social hour or cocktail party, with multiple simultaneous conversations. Some people must like such events and even find relaxing. I tend to find them uncomfortable and a bit of a chore to mentally process, at least until I can get deep enough into a conversation with 1 or 2 people to tune everyone else out. So, while a bit of business *might* get conducted, that is not the primary purpose. So I can see that pushing to make it a business meeting would not be too welcome. What I would like is an online sprint with a temporary #python-triage channel, with at least one commit-developer present. Pending that, is there any time of day when more people with commit privileges are likely to be present. The other problem I have is being dropped or timed out, and not having/knowing a way to get auto-reconnected to the channel. Thus, I could miss a response even if I do get one. -- Terry Jan Reedy
On Wed, 14 Jul 2010 12:34:27 -0400 Terry Reedy <tjreedy@udel.edu> wrote:
So I can see that pushing to make it a business meeting would not be too welcome. What I would like is an online sprint with a temporary #python-triage channel, with at least one commit-developer present.
It should be noted that #python-dev is quite low-traffic. There is less than one message per minute on average, and not often more than one conversation at a time.
Pending that, is there any time of day when more people with commit privileges are likely to be present.
Generally any time of day, since different people are on different timezones.
The other problem I have is being dropped or timed out, and not having/knowing a way to get auto-reconnected to the channel. Thus, I could miss a response even if I do get one.
I never get drops or timeouts. I suppose any decent IRC client will handle connection issues for you. Regards Antoine.
On 7/14/2010 12:58 PM, Antoine Pitrou wrote:
On Wed, 14 Jul 2010 12:34:27 -0400 Terry Reedy<tjreedy@udel.edu> wrote:
So I can see that pushing to make it a business meeting would not be too welcome. What I would like is an online sprint with a temporary #python-triage channel, with at least one commit-developer present.
It should be noted that #python-dev is quite low-traffic. There is less than one message per minute on average, and not often more than one conversation at a time.
I will take a look.
The other problem I have is being dropped or timed out, and not having/knowing a way to get auto-reconnected to the channel. Thus, I could miss a response even if I do get one.
I never get drops or timeouts. I suppose any decent IRC client will handle connection issues for you.
Is Chatzilla not decent, or is there a better Windows client. I have it set to reconnect when disconnected and to 'msg NickServe identify' when connected, but I do not see any way to wait for that to complete before issuing 'join #python'. I found a box under #python for 'rejoin when kicked' but I do not know if that will work for disconnections. -- Terry Jan Reedy
Terry Reedy wrote:
On 7/14/2010 4:10 AM, Georg Brandl wrote:
Sure, and if it was work time, we probably would do this ;). As it is right now, this is volunteer time, and I would say that we're entitled to do whatever helps us getting done the (not always exciting) work, and our IRC crap talk, if that's what it is, happens to be among that.
Aha! IRC ('chat') is like a social hour or cocktail party, with multiple simultaneous conversations. Some people must like such events and even find relaxing. I tend to find them uncomfortable and a bit of a chore to mentally process, at least until I can get deep enough into a conversation with 1 or 2 people to tune everyone else out. So, while a bit of business *might* get conducted, that is not the primary purpose.
So I can see that pushing to make it a business meeting would not be too welcome. What I would like is an online sprint with a temporary #python-triage channel, with at least one commit-developer present.
Pending that, is there any time of day when more people with commit privileges are likely to be present.
The other problem I have is being dropped or timed out, and not having/knowing a way to get auto-reconnected to the channel. Thus, I could miss a response even if I do get one.
Speak to the twisted guys. It's about a line-and-a-half of code to run a logger on an IRC channel. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 DjangoCon US September 7-9, 2010 http://djangocon.us/ See Python Video! http://python.mirocommunity.org/ Holden Web LLC http://www.holdenweb.com/
On Wed, Jul 14, 2010 at 11:34, Terry Reedy <tjreedy@udel.edu> wrote:
On 7/14/2010 4:10 AM, Georg Brandl wrote:
Sure, and if it was work time, we probably would do this ;). As it is
right now, this is volunteer time, and I would say that we're entitled to do whatever helps us getting done the (not always exciting) work, and our IRC crap talk, if that's what it is, happens to be among that.
Pending that, is there any time of day when more people with commit privileges are likely to be present.
There never seems to be a lack of committers online. There are plenty of us here in the US, along with numerous committers from a host of European countries and elsewhere, so committer availability tends to follow the sun. Knowing that you are in the US, I don't think you'll come across many dead-zones.
Martin v. Löwis wrote:
Initially (five years ago!) I tried to overcome these issues by improving IDLE, solving problems and adding a few key features. Without going into details, suffice to say that IDLE hasn't improved much since 2005 despite my efforts. For example, see http://bugs.python.org/issue1529142, where it took nearly 3 years to fix a major issue from the moment I posted the first workaround. For another example, see http://bugs.python.org/issue3068, where I posted a patch for an extension configuration dialog over two years ago, and it hasn't received as much as a sneeze in response.
I can understand that this is frustrating, ...
I am not writing this to vent my frustration, and have purposely avoided making that the issue.
... but please understand that this is not specific to your patches, or to IDLE. Many other patches on bugs.python.org remain unreviewed for many years. That's because many of the issues are really tricky, and there are very few people who both have the time and the expertise to evaluate them.
I am aware of the situation with regard to issue reviews, but I think with IDLE there is more going on. In other parts of the Python codebase, a workaround for a major usability issue wouldn't normally have taken nearly three years to resolve after a working patch was submitted. And a working, well-tested patch wouldn't normally have sat ignored for over two years. Well, perhaps these things happen occasionally, but with IDLE this is the norm.
FWIW, I don't consider a few months as a "long" time for a patch review. At the moment, I'm personally able to perhaps review one issue per week (sometimes less); at this rate, it'll take several years until I get to everything.
I'm not talking about a few months, I'm talking about at least six months in most cases, years in many cases, as in the examples I mentioned. - Tal Einat
I am aware of the situation with regard to issue reviews, but I think with IDLE there is more going on. In other parts of the Python codebase, a workaround for a major usability issue wouldn't normally have taken nearly three years to resolve after a working patch was submitted.
Oh sure it does. Just look at all the cross-compilation bug reports and patches that get submitted.
And a working, well-tested patch wouldn't normally have sat ignored for over two years. Well, perhaps these things happen occasionally, but with IDLE this is the norm.
Unfortunately, they happen more often than you think. Regards, Martin
On 11/07/2010 23:18, Tal Einat wrote:
Martin v. Löwis wrote:
Initially (five years ago!) I tried to overcome these issues by improving IDLE, solving problems and adding a few key features. Without going into details, suffice to say that IDLE hasn't improved much since 2005 despite my efforts. For example, see http://bugs.python.org/issue1529142, where it took nearly 3 years to fix a major issue from the moment I posted the first workaround. For another example, see http://bugs.python.org/issue3068, where I posted a patch for an extension configuration dialog over two years ago, and it hasn't received as much as a sneeze in response.
I can understand that this is frustrating, ...
I am not writing this to vent my frustration, and have purposely avoided making that the issue.
... but please understand that this is not specific to your patches, or to IDLE. Many other patches on bugs.python.org remain unreviewed for many years. That's because many of the issues are really tricky, and there are very few people who both have the time and the expertise to evaluate them.
I am aware of the situation with regard to issue reviews, but I think with IDLE there is more going on. In other parts of the Python codebase, a workaround for a major usability issue wouldn't normally have taken nearly three years to resolve after a working patch was submitted. And a working, well-tested patch wouldn't normally have sat ignored for over two years. Well, perhaps these things happen occasionally, but with IDLE this is the norm.
FWIW, I don't consider a few months as a "long" time for a patch review. At the moment, I'm personally able to perhaps review one issue per week (sometimes less); at this rate, it'll take several years until I get to everything.
I'm not talking about a few months, I'm talking about at least six months in most cases, years in many cases, as in the examples I mentioned.
- Tal Einat
I can understand your frustration, but in response to an appeal from Terry Reedy some weeks back on c.l.py I've done a substantial amount of work in the last couple of weeks to clear outstanding issues, sadly IDLE just sits in the pile. Ow, but hang on a minute, I've already volunteered TJR to take this on, I believe he's up for it, I'll support him up to the hilt, so why the hell can't we get on with it? Or would the triage team as it stands object cos they'll be put out of a job? :) Kindest regards. Mark Lawrence.
2010/7/11 Mark Lawrence <breamoreboy@yahoo.co.uk>:
I can understand your frustration, but in response to an appeal from Terry Reedy some weeks back on c.l.py I've done a substantial amount of work in the last couple of weeks to clear outstanding issues, sadly IDLE just sits in the pile. Ow, but hang on a minute, I've already volunteered TJR to take this on, I believe he's up for it, I'll support him up to the hilt, so why the hell can't we get on with it? Or would the triage team as it stands object cos they'll be put out of a job? :)
And as Martin has already noted, only Terry can volunteer himself. -- Regards, Benjamin
On Jul 11, 2010, at 10:22 AM, Tal Einat wrote:
Most of the responses up to this point have been strongly against my proposal. The main reason given is that it is nice to have a graphical IDE supported out-of-the-box with almost any Python installation. This is especially important for novice programmers and in teaching environments. I understand this sentiment, but I think that supplying a quirky IDE with many caveats, lacking documentation, some bugs and a partially working debugger ends up causing more confusion than good.
The people who are actually *in* those environments seem to disagree with you :). I think you underestimate the difficulty of getting software installed and overestimate the demands of new Python users and students. While I don't ever use IDLE if there's an alternative available, I have been very grateful many times for its presence in environments where it was a struggle even to say "install Python". A workable editor and graphical shell is important, whatever its flaws. (And I think you exaggerate IDLE's flaws just a bit.)
Glyph Lefkowitz wrote:
On Jul 11, 2010, at 10:22 AM, Tal Einat wrote:
The people who are actually *in* those environments seem to disagree with you :). I think you underestimate the difficulty of getting software installed and overestimate the demands of new Python users and students. While I don't ever use IDLE if there's an alternative available, I have been very grateful many times for its presence in environments where it was a struggle even to say "install Python". A workable editor and graphical shell is important, whatever its flaws. (And I think you exaggerate IDLE's flaws just a bit.)
I would like to note that I am one of those in those environments. I have used IDLE to teach Python to new users, and their opinion of IDLE (and Python as a consequence) wasn't great, precisely because of the bugs and quirks. Recently I have stopped recommending IDLE for beginners and have found that this avoids quite a few snags, which is significant. I have also been in environments where installing anything was problematic and having IDLE available out-of-the-box was supposed to be a clear win. I certainly used it, but all of my coworkers (experienced Pythonistas who have worked with IDLE before) ended up preferring the basic interpreter and text editors such as vim, despite my advocacy of IDLE, because they tired of IDLE's snags (e.g. the inability to run several instances in parallel). My point is that I don't think I am exaggerating IDLE's flaws. I'm not saying that it is no longer usable or useful, but I am saying that its current state is not "okay". - Tal Einat
My point is that I don't think I am exaggerating IDLE's flaws. I'm not saying that it is no longer usable or useful, but I am saying that its current state is not "okay".
So can you produce a list of patches that you think can be accepted as-is? Preferably, make to lists: bug fixes, and new features. The bug fixes could be either for 2.x or 3.x; the new features would preferably be for just 3.x. Regards, Martin
On Mon, Jul 12, 2010 at 1:41 AM, "Martin v. Löwis" <martin@v.loewis.de> wrote:
My point is that I don't think I am exaggerating IDLE's flaws. I'm not saying that it is no longer usable or useful, but I am saying that its current state is not "okay".
So can you produce a list of patches that you think can be accepted as-is?
That's not a fair question! There have been several such patches, but most will likely need revision since they have been sitting around untouched for so long. And there would have been many more patches if the existing ones would have been addressed. Getting a few current patches accepted is not the reason I posted here. - Tal Einat
Am 12.07.2010 13:01, schrieb Tal Einat:
On Mon, Jul 12, 2010 at 1:41 AM, "Martin v. Löwis" <martin@v.loewis.de> wrote:
My point is that I don't think I am exaggerating IDLE's flaws. I'm not saying that it is no longer usable or useful, but I am saying that its current state is not "okay".
So can you produce a list of patches that you think can be accepted as-is?
That's not a fair question!
There have been several such patches, but most will likely need revision since they have been sitting around untouched for so long. And there would have been many more patches if the existing ones would have been addressed.
Getting a few current patches accepted is not the reason I posted here.
Ok. Then I guess I cannot help further - I certainly don't support removal of IDLE from the standard library. Regards, Martin
On Sun, Jul 11, 2010 at 05:22:28PM +0300, Tal Einat wrote:
Initially (five years ago!) I tried to overcome these issues by improving IDLE, solving problems and adding a few key features. Without going into details, suffice to say that IDLE hasn't improved much since 2005 despite my efforts. For example, see
Is it maybe time for another idle-fork project to develop IDLE outside the stdlib for a while, and then the forked version could be swallowed wholesale by the Python 3.2 release? --amk
On 11/07/2010 20:47, A.M. Kuchling wrote:
On Sun, Jul 11, 2010 at 05:22:28PM +0300, Tal Einat wrote:
Initially (five years ago!) I tried to overcome these issues by improving IDLE, solving problems and adding a few key features. Without going into details, suffice to say that IDLE hasn't improved much since 2005 despite my efforts. For example, see
Is it maybe time for another idle-fork project to develop IDLE outside the stdlib for a while, and then the forked version could be swallowed wholesale by the Python 3.2 release?
Whilst I would *really* like to see bugfixes and minor improvements in functionality incorporated back into IDLE (who wouldn't?) I think it is important that IDLE remains focused on its nice of being a "simple" or "beginners" IDE, without trying to become a full blown IDE that is even harder for us to maintain. Speaking of which, the IDLE.app that comes with Python 2.7 for Mac OS X isn't working for me. Anyone else seeing that? All the best, Michael Foord
--amk _______________________________________________ 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.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tal Einat wrote:
I would like to propose removing IDLE from the standard library.
I have been using IDLE since 2002 and have been doing my best to help maintain and further develop IDLE since 2005.
I'm surprised by the amount of interest this has raised already. To answer a few questions that were raised:
In recent years I have worked up many patches, both bugfixes and new features and improvements. Getting any attention to these was non-trivial, and getting patches accepted (or an explanation why they are rejected in some cases) almost always took many months, sometimes years, and some are still unresolved. It has been very frustrating.
When I ran into bugs I fixed them and submitted a patch. I have also done so for quite a few bugs reported by others. However, there are currently several bugs in the tracker which nobody is taking any notice of. IIRC most of the recent bugs are related to OSX or 64-bit Windows.
To those who mention that IDLE is "okay" or "not going uphill", my grandfather would say "if you aren't running forwards, you are falling behind." You should know how IDLE looks to programmers seeing it for the first time -- IDLE's quirky and old-fashioned looks and interface are a major turnoff for new users. As a result I have stopped recommending it to coworkers, despite personally liking IDLE, instead recommending the basic command-line or IPython for interactive work, and any other IDE or text editor for development.
I too prefer IDLE to the basic command line, and think that something like IDLE is well-suited for learning/teaching Python. I also think an interpreter with a nice GUI can be far superior to a text-only interpreter. However, I've mostly lost hope for IDLE, and am currently hoping that something else takes its place.
The fact is that for many years little effort has gone into developing and maintaining IDLE, and I believe being tucked in a corner of the Python codebase is a major reason for this. I really don't see why IDLE has to be part of the standard library, what's wrong with IDLE being an externally maintained application?
Yes, IDLE still works (mostly), but us few who continue to use it could do so even if it weren't part of the standard library.
I wonder if moving it out of stdlib might actually help improve its development velocity: maybe if it were managed via bitbucket, with user-visible forks to known fixes, etc., it would get "caught up" to people's expectations. Perhaps I'm really suggesting that there be an 'idle2' project nn bitbucket, as a "friendly fork" of the mostly freeze-dried version in stdlib. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkw7JcAACgkQ+gerLs4ltQ73RACfTcPaDXPFlg8EWnBxYj3qfWwg qswAn3Ws/FvYqLLiYGvgzEpd1sIpWuWJ =ZlSp -----END PGP SIGNATURE-----
On 07/10/2010 06:05 PM, Tal Einat wrote:
Hello,
I would like to propose removing IDLE from the standard library.
I have been using IDLE since 2002 and have been doing my best to help maintain and further develop IDLE since 2005.
In recent years IDLE has received negligible interest and attention from the Python community. During this time IDLE has slowly gone downhill. The documentation and tutorials grow increasingly out of date. Cross-platform support has degraded with the increasing popularity of OSX and 64-bit platforms. Bugs take months, and sometimes more than a year, to be solved. Features that have since become common-place, such as having a non-intrusive search box instead of a dialog, are obviously and painfully lacking, making IDLE feel clumsy and out-dated.
For these reasons, I think it would be fitting to remove IDLE from the standard library. IDLE is no longer recommended to beginners, IMO rightfully so, and this was the main reason for its inclusion in the standard library. Furthermore, if there is little or no interest in developing and maintaining IDLE, it should be removed to avoid having buggy and badly supported software in the standard library.
There might be another alternative. Both idle and pydoc are applications (are there others?) that are in the standard library. As such, they or parts of them, are possibly importable to other projects. That restricts changes because a committer needs to consider the chances that a change may break something else. I suggest they be moved out of the lib directory, but still be included with python. (Possibly in the tools directory.) That removes some of the backward compatibility restrictions or at least makes it clear there isn't a need for backward compatibility. Would a change of this sort help make things any easier? (Note: idle isn't in the lib directory on Ubuntu.) Ron
On Sun, Jul 11, 2010 at 3:38 PM, Ron Adam <rrr@ronadam.com> wrote:
There might be another alternative.
Both idle and pydoc are applications (are there others?) that are in the standard library. As such, they or parts of them, are possibly importable to other projects. That restricts changes because a committer needs to consider the chances that a change may break something else.
I suggest they be moved out of the lib directory, but still be included with python. (Possibly in the tools directory.) That removes some of the backward compatibility restrictions or at least makes it clear there isn't a need for backward compatibility.
I also like this idea. This means Python comes with an IDE "out of he box" but without the overhead of a management and release process that is built for something very different than a GUI program (the standard library). This would mean that IDLE would be in site-packages, could easily be upgraded using normal tools, and maybe most importantly it could have its own community tools and development process that is more casual (and can more easily integrate new contributors) and higher velocity of changes and releases. Python releases would then ship the most recent stable release of IDLE. -- Ian Bicking | http://blog.ianbicking.org
On 12/07/2010 19:21, Ian Bicking wrote:
On Sun, Jul 11, 2010 at 3:38 PM, Ron Adam <rrr@ronadam.com <mailto:rrr@ronadam.com>> wrote:
There might be another alternative.
Both idle and pydoc are applications (are there others?) that are in the standard library. As such, they or parts of them, are possibly importable to other projects. That restricts changes because a committer needs to consider the chances that a change may break something else.
I suggest they be moved out of the lib directory, but still be included with python. (Possibly in the tools directory.) That removes some of the backward compatibility restrictions or at least makes it clear there isn't a need for backward compatibility.
I also like this idea. This means Python comes with an IDE "out of he box" but without the overhead of a management and release process that is built for something very different than a GUI program (the standard library). This would mean that IDLE would be in site-packages, could easily be upgraded using normal tools, and maybe most importantly it could have its own community tools and development process that is more casual (and can more easily integrate new contributors) and higher velocity of changes and releases. Python releases would then ship the most recent stable release of IDLE.
IDLE itself is probably stable enough that being able to "upgrade in place" is not a high priority. That could change based on this thread of course. I would *really* support this approach with "pip" once distutils2 is complete and integrated into the standard library. I would really like Python to come with a capable package manager "out of the box" but understand your reluctance to tie pip to the Python release schedule. Having pip installed into site-packages by default, so that it *can* be upgraded in place, would be win-win as far as I can tell. Slight thread hijacking I realise... :-) All the best, Michael
-- Ian Bicking | http://blog.ianbicking.org
_______________________________________________ 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 07/12/2010 01:21 PM, Ian Bicking wrote:
On Sun, Jul 11, 2010 at 3:38 PM, Ron Adam <rrr@ronadam.com <mailto:rrr@ronadam.com>> wrote:
There might be another alternative.
Both idle and pydoc are applications (are there others?) that are in the standard library. As such, they or parts of them, are possibly importable to other projects. That restricts changes because a committer needs to consider the chances that a change may break something else.
I suggest they be moved out of the lib directory, but still be included with python. (Possibly in the tools directory.) That removes some of the backward compatibility restrictions or at least makes it clear there isn't a need for backward compatibility.
I also like this idea. This means Python comes with an IDE "out of he box" but without the overhead of a management and release process that is built for something very different than a GUI program (the standard library). This would mean that IDLE would be in site-packages, could easily be upgraded using normal tools, and maybe most importantly it could have its own community tools and development process that is more casual (and can more easily integrate new contributors) and higher velocity of changes and releases. Python releases would then ship the most recent stable release of IDLE.
Yes, if you follow the guide lines for the rest of the library, anything that is removed needs to be depreciated first and anything thats added needs to be carefully looked at to be sure it doesn't break anything that may depend on it. That is good for the rest of the standard library but really slows things down for an application like idle. Just removing those restrictions would make things a lot simpler and speed things up considerably I think. The site-packages directory is still in the lib path and so things there are still importable. That is why I suggested the tools directory. Another place would be in the same directory the python executable lives. But the exact location isn't really the important thing, having a clear policy on how the upgrade policy differs from the python library is what is needed. Ron Ron
Tal Einat wrote:
I would like to propose removing IDLE from the standard library.
I use IDLE every day. It does everything I want an IDE to do, it looks simple and doesn't waste screen real estate like some other IDEs do, it supports proportionally spaced fonts correctly, its syntax coloring is easy configurable (not a nightmare like some scintilla-based IDEs), and it's instantly available on any PC on which I install Python. I'd like to keep it in the stdlib. Greetings,
On 7/12/10 10:16 AM, Michiel Overtoom wrote:
Tal Einat wrote:
I would like to propose removing IDLE from the standard library.
I use IDLE every day. It does everything I want an IDE to do, it looks simple and doesn't waste screen real estate like some other IDEs do, it supports proportionally spaced fonts correctly, its syntax coloring is easy configurable (not a nightmare like some scintilla-based IDEs), and it's instantly available on any PC on which I install Python.
I'd like to keep it in the stdlib.
+1 to keeping it in the stdlib, in case my earlier comments didn't make that clear. My own reasons for submitting patches to help with Tkinter on the Mac are pretty typical: the Cocoa-based implementation of Tk broke some things in IDLE because of different methods for menu placement, etc. I wanted this fixed, and since I might be the only Python person with the knowledge about Carbon vs. Cocoa internals in Tk to do it, I dug in, attempted to grok IDLE's rather baroque code, and eventually came up with some patches. Scratching my own itch, IOW. I'm currently using Aquamacs/Emacs for my Python development because of some other issues with Tk-Cocoa (external to IDLE) on Leopard, but once I upgrade my OS, I plan to return to using IDLE for everyday Python development. Since Tkinter is my GUI toolkit of choice, I like to work in that environment. Also, I strongly urge Guilherme (or someone) to commit his changes to IDLE. While I like IDLE and feel it is a very useful IDE for Python work even for someone who is past the beginner stage, I also agree that its current UI is dated. Adding the themed Tk widgets would likely make it more pleasant to use, as well as showing what can be done with the new widgets. (The existence and widespread use of archaic Tk extensions like Tix within Tkinter isn't a recommendation for the toolkit beyond backwards compatibility.) --Kevin -- Kevin Walzer Code by Kevin http://www.codebykevin.com
participants (33)
-
"Martin v. Löwis" -
A.M. Kuchling -
Antoine Pitrou -
Benjamin Peterson -
Bill Janssen -
Brett Cannon -
Brian Curtin -
Georg Brandl -
geremy condra -
Glyph Lefkowitz -
Guilherme Polo -
Ian Bicking -
Jeroen Ruigrok van der Werven -
Jesse Noller -
Kevin Walzer -
Kurt B. Kaiser -
Mark Lawrence -
Mark Summerfield -
Michael Foord -
Michiel Overtoom -
Miki Tebeka -
Nick Coghlan -
Paul Moore -
R. David Murray -
Raymond Hettinger -
Ron Adam -
Ronald Oussoren -
Stefan Krah -
Stephen Hansen -
Steve Holden -
Tal Einat -
Terry Reedy -
Tres Seaver