From taleinat at gmail.com Sun Jul 11 01:05:22 2010 From: taleinat at gmail.com (Tal Einat) Date: Sun, 11 Jul 2010 02:05:22 +0300 Subject: [Idle-dev] Removing IDLE from the standard library Message-ID: 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From tjreedy at udel.edu Sun Jul 11 03:33:28 2010 From: tjreedy at udel.edu (Terry Reedy) Date: Sat, 10 Jul 2010 21:33:28 -0400 Subject: [Idle-dev] Removing IDLE from the standard library In-Reply-To: References: Message-ID: 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 From kw at codebykevin.com Sun Jul 11 03:40:00 2010 From: kw at codebykevin.com (Kevin Walzer) Date: Sat, 10 Jul 2010 21:40:00 -0400 Subject: [Idle-dev] Removing IDLE from the standard library In-Reply-To: References: Message-ID: <4C3920F0.4000709@codebykevin.com> On 7/10/10 7:05 PM, Tal Einat wrote: > > 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. I have a few questions: 1. Is the issue that no one is filing patches, or that the patches are not being applied? I've filed some (rather involved) patches to improve IDLE's support on OS X/Snow Leopard (where Tk is built on Cocoa instead of Carbon) and they have never been applied. 2. A search dialog vs. a search box is partly a matter of taste, don't you think? 3. One issue that would greatly help IDLE would be to integrate the new themed ttk widgets--has this happened in Python 2.7 or 3.1? > > 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 disagree that IDLE should be removed. I find it very useful. I wonder if the issue is overworked maintainers who don't have time to apply patches that are submitted. Certainly people should provide patches if they are able. After all, IDLE/idleib is pure-Python, not at the C level. --Kevin -- Kevin Walzer Code by Kevin http://www.codebykevin.com From ggpolo at gmail.com Sun Jul 11 06:03:12 2010 From: ggpolo at gmail.com (Guilherme Polo) Date: Sun, 11 Jul 2010 01:03:12 -0300 Subject: [Idle-dev] Removing IDLE from the standard library In-Reply-To: <4C3920F0.4000709@codebykevin.com> References: <4C3920F0.4000709@codebykevin.com> Message-ID: 2010/7/10 Kevin Walzer : > > 3. One issue that would greatly help IDLE would be to integrate the new > themed ttk widgets--has this happened in Python 2.7 or 3.1? > I did that some two years ago, either on a separated branch or a separated repo (don't remember right now). I believe it was mostly just to show how IDLE would look like with it, but it was also extended to use tabs instead of separated windows (except for shell and edit windows, I think -- memory failing). Anyway, I don't think it will be easy to repatch the current IDLE using this previous patch (especially because there is only a single patch with all the changes) but the visual result can be seen at the first screenshot here: http://code.google.com/p/python-ttk/wiki/Screenshots. Maybe what is actually important is providing better usability than just giving a prettier UI, but this tends to involve discussion and there isn't enough people interested on discussing it. Things like not needing to save a file before running or making the help window non-modal have been done and in my opinion both improve usability but there isn't a huge interesting on having them. Maybe people don't care about these things at all, or maybe the people that care don't even know they can file a bug report. So .. (finally) .. updating IDLE to use ttk widgets when available might cause two things (as I see it): several new minor bugs and consequently getting more involvement of the current developers on improving the IDE; or, several new minor bugs followed by reverting to the previous version. At this point I'm not sure that doing this update is going to help IDLE. -- -- Guilherme H. Polo Goncalves From ggpolo at gmail.com Sun Jul 11 06:23:38 2010 From: ggpolo at gmail.com (Guilherme Polo) Date: Sun, 11 Jul 2010 01:23:38 -0300 Subject: [Idle-dev] [Python-Dev] Removing IDLE from the standard library In-Reply-To: References: Message-ID: 2010/7/10 Miki Tebeka : > 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 From ronaldoussoren at mac.com Sun Jul 11 08:20:57 2010 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Sun, 11 Jul 2010 08:20:57 +0200 Subject: [Idle-dev] [Python-Dev] Removing IDLE from the standard library In-Reply-To: References: Message-ID: On 11 Jul, 2010, at 6:23, Guilherme Polo wrote: > 2010/7/10 Miki Tebeka : >> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3567 bytes Desc: not available URL: From ronaldoussoren at mac.com Sun Jul 11 08:22:45 2010 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Sun, 11 Jul 2010 08:22:45 +0200 Subject: [Idle-dev] Removing IDLE from the standard library In-Reply-To: References: Message-ID: <20F50EEB-2336-41D9-B530-EC3A4EE7A46E@mac.com> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3567 bytes Desc: not available URL: From taleinat at gmail.com Sun Jul 11 10:57:18 2010 From: taleinat at gmail.com (Tal Einat) Date: Sun, 11 Jul 2010 11:57:18 +0300 Subject: [Idle-dev] Removing IDLE from the standard library In-Reply-To: References: Message-ID: > 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 From ronaldoussoren at mac.com Sun Jul 11 11:03:42 2010 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Sun, 11 Jul 2010 11:03:42 +0200 Subject: [Idle-dev] Removing IDLE from the standard library In-Reply-To: References: Message-ID: <7EF8C99A-4163-461A-922B-1FF3003D89E2@mac.com> 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3567 bytes Desc: not available URL: From taleinat at gmail.com Sun Jul 11 11:38:11 2010 From: taleinat at gmail.com (Tal Einat) Date: Sun, 11 Jul 2010 12:38:11 +0300 Subject: [Idle-dev] Removing IDLE from the standard library In-Reply-To: <7EF8C99A-4163-461A-922B-1FF3003D89E2@mac.com> References: <7EF8C99A-4163-461A-922B-1FF3003D89E2@mac.com> Message-ID: 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 From kw at codebykevin.com Sun Jul 11 15:24:54 2010 From: kw at codebykevin.com (Kevin Walzer) Date: Sun, 11 Jul 2010 09:24:54 -0400 Subject: [Idle-dev] Removing IDLE from the standard library In-Reply-To: <7EF8C99A-4163-461A-922B-1FF3003D89E2@mac.com> References: <7EF8C99A-4163-461A-922B-1FF3003D89E2@mac.com> Message-ID: <4C39C626.40400@codebykevin.com> 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 From taleinat at gmail.com Sun Jul 11 16:22:28 2010 From: taleinat at gmail.com (Tal Einat) Date: Sun, 11 Jul 2010 17:22:28 +0300 Subject: [Idle-dev] Removing IDLE from the standard library In-Reply-To: References: Message-ID: 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 From taleinat at gmail.com Sun Jul 11 16:31:03 2010 From: taleinat at gmail.com (Tal Einat) Date: Sun, 11 Jul 2010 17:31:03 +0300 Subject: [Idle-dev] [Python-Dev] Removing IDLE from the standard library Message-ID: Guido van Rossum wrote: >David Beazley wrote: >> >>> I would like to propose removing IDLE from the standard library. >>> >> >> -1000. From the Python training department, I would like to say that this would be a horrible idea. > >Right. IDLE fits a niche. It's never going to be the world's best >Python development environment but it isn't the worst either, and it's >worth keeping around. > >There clearly are *some* folks who care enough about IDLE to submit >bug reports and fixes. How about we empower these people by giving at >least one of them commit privileges? IDLE development has often been >done by people who aren't otherwise contributing to the core, and we >surely should trust those folks with commit privileges. This would certainly be a great improvement on the current situation. However, I still think IDLE is not currently in a state that it should be suggested for use by beginners. - Tal Einat From kw at codebykevin.com Sun Jul 11 17:14:27 2010 From: kw at codebykevin.com (Kevin Walzer) Date: Sun, 11 Jul 2010 11:14:27 -0400 Subject: [Idle-dev] Removing IDLE from the standard library In-Reply-To: References: Message-ID: <4C39DFD3.6040304@codebykevin.com> On 7/11/10 10:22 AM, Tal Einat wrote: > Having IDLE in the stdlib may be > convenient for a few people, but most never use it and don't care > about it. This is not a compelling argument. I don't use sqlite or anydbm, but I'm not advocating for their removal from the standard library. -- Kevin Walzer Code by Kevin http://www.codebykevin.com From taleinat at gmail.com Sun Jul 11 17:20:55 2010 From: taleinat at gmail.com (Tal Einat) Date: Sun, 11 Jul 2010 18:20:55 +0300 Subject: [Idle-dev] Removing IDLE from the standard library In-Reply-To: <4C39DFD3.6040304@codebykevin.com> References: <4C39DFD3.6040304@codebykevin.com> Message-ID: Kevin Walzer wrote: > On 7/11/10 10:22 AM, Tal Einat wrote: >> >> Having IDLE in the stdlib may be >> convenient for a few people, but most never use it and don't care >> about it. > > This is not a compelling argument. I don't use sqlite or anydbm, but I'm not > advocating for their removal from the standard library. The (hopefully) compelling arguments were others, such as the sentence following the one you quoted: "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." The sentence you quoted was in response to those few who said that they like having IDLE available out-of-the-box -- *that* is not a compelling argument for leaving IDLE in the stdlib in its current state. - Tal Einat From glyph at twistedmatrix.com Sun Jul 11 20:56:18 2010 From: glyph at twistedmatrix.com (Glyph Lefkowitz) Date: Sun, 11 Jul 2010 14:56:18 -0400 Subject: [Idle-dev] Removing IDLE from the standard library In-Reply-To: References: Message-ID: <217B30F6-06FE-4237-90C2-540CD6BB6A28@twistedmatrix.com> 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.) -------------- next part -------------- An HTML attachment was scrubbed... URL: From glyph at twistedmatrix.com Sun Jul 11 20:59:14 2010 From: glyph at twistedmatrix.com (Glyph Lefkowitz) Date: Sun, 11 Jul 2010 14:59:14 -0400 Subject: [Idle-dev] [Python-Dev] Removing IDLE from the standard library In-Reply-To: <4C3A0F85.1090404@v.loewis.de> References: <4C3A0F85.1090404@v.loewis.de> Message-ID: 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". -------------- next part -------------- An HTML attachment was scrubbed... URL: From taleinat at gmail.com Mon Jul 12 00:18:22 2010 From: taleinat at gmail.com (Tal Einat) Date: Mon, 12 Jul 2010 01:18:22 +0300 Subject: [Idle-dev] [Python-Dev] Removing IDLE from the standard library In-Reply-To: <4C3A0F85.1090404@v.loewis.de> References: <4C3A0F85.1090404@v.loewis.de> Message-ID: 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 From ggpolo at gmail.com Mon Jul 12 00:29:26 2010 From: ggpolo at gmail.com (Guilherme Polo) Date: Sun, 11 Jul 2010 19:29:26 -0300 Subject: [Idle-dev] [Python-Dev] Removing IDLE from the standard library In-Reply-To: <4C3A415F.6050709@v.loewis.de> References: <4C3A0F85.1090404@v.loewis.de> <11989_1278874767_o6BIxON2026376_EA883BC9-5C6B-4444-B0D7-1BA51815328F@twistedmatrix.com> <4C3A415F.6050709@v.loewis.de> Message-ID: 2010/7/11 "Martin v. L?wis" : >> In the 2009 Google Summer of Code I was the mentor for a Brazilian >> student, Guilherme Polo, who completed and extended important >> improvements to IDLE made during the previous year by David Scherer. >> Given the somewhat official nature of this work, I assumed that these >> needed improvements would make it into the standard distribution, but as >> far as I know that hasn't happened. It would seem that if even this >> "sponsored" project didn't impact the standard Python distribution, >> something is broken in the procedures, and probably what is needed is, >> as Guido says, that someone be given the authority to get improvements >> to IDLE into the standard distribution. Making a significant change to >> the update procedures is clearly needed. > > I don't think so; instead, the perception of authority needs to be > adjusted (in the specific case). Guilherme could have committed these > changes, but, for whatever reason, decided not to. Nor did his direct > mentor (i.e. you) tell him to commit the changes, and neither did I. > >> Even if this needed change is made, there is also merit to Tai's >> suggestion of creating a separate project, to encourage developers like >> him to work together to improve IDLE, without having as a first priority >> to worry about getting it into the standard distribution, but with the >> clear understanding that this is the place to go for improvements to >> migrate into the standard distribution. > > Again, Guilherme could commit his changes any time. > > Regards, > Martin I think Martin has always supported me in some way and I really appreciate that. But, maybe because I won commit privileges solely based on GSoC work, I felt other developers wouldn't approve my commits without previous discussion and that is the major reason for not committing most of my patches. -- -- Guilherme H. Polo Goncalves From taleinat at gmail.com Mon Jul 12 00:31:20 2010 From: taleinat at gmail.com (Tal Einat) Date: Mon, 12 Jul 2010 01:31:20 +0300 Subject: [Idle-dev] Removing IDLE from the standard library In-Reply-To: <217B30F6-06FE-4237-90C2-540CD6BB6A28@twistedmatrix.com> References: <217B30F6-06FE-4237-90C2-540CD6BB6A28@twistedmatrix.com> Message-ID: 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 From taleinat at gmail.com Mon Jul 12 00:39:19 2010 From: taleinat at gmail.com (Tal Einat) Date: Mon, 12 Jul 2010 01:39:19 +0300 Subject: [Idle-dev] [Python-Dev] Removing IDLE from the standard library In-Reply-To: References: <4C3A0F85.1090404@v.loewis.de> <11989_1278874767_o6BIxON2026376_EA883BC9-5C6B-4444-B0D7-1BA51815328F@twistedmatrix.com> <4C3A415F.6050709@v.loewis.de> Message-ID: Guilherme Polo wrote: > 2010/7/11 "Martin v. L?wis" : >>> In the 2009 Google Summer of Code I was the mentor for a Brazilian >>> student, Guilherme Polo, who completed and extended important >>> improvements to IDLE made during the previous year by David Scherer. >>> Given the somewhat official nature of this work, I assumed that these >>> needed improvements would make it into the standard distribution, but as >>> far as I know that hasn't happened. It would seem that if even this >>> "sponsored" project didn't impact the standard Python distribution, >>> something is broken in the procedures, and probably what is needed is, >>> as Guido says, that someone be given the authority to get improvements >>> to IDLE into the standard distribution. Making a significant change to >>> the update procedures is clearly needed. >> >> I don't think so; instead, the perception of authority needs to be >> adjusted (in the specific case). Guilherme could have committed these >> changes, but, for whatever reason, decided not to. Nor did his direct >> mentor (i.e. you) tell him to commit the changes, and neither did I. >> >>> Even if this needed change is made, there is also merit to Tai's >>> suggestion of creating a separate project, to encourage developers like >>> him to work together to improve IDLE, without having as a first priority >>> to worry about getting it into the standard distribution, but with the >>> clear understanding that this is the place to go for improvements to >>> migrate into the standard distribution. >> >> Again, Guilherme could commit his changes any time. >> >> Regards, >> Martin > > I think Martin has always supported me in some way and I really > appreciate that. But, maybe because I won commit privileges solely > based on GSoC work, I felt other developers wouldn't approve my > commits without previous discussion and that is the major reason for > not committing most of my patches. FWIW this is why I started IDLE-Spoon (well, continued Noam Raphael's project of the same name, in a sense). The idea was to have a fork of IDLE with new features which need to be tried out by "beta testers" to iron out all of the glitches before making it into the main version, like IDLE-fork back in the beginning of the decade. However I have utterly failed in promoting this project and getting "beta testers" on board, at least partially due to the lack of interest from the community (and admittedly my lack of PR skills). - Tal Einat From breamoreboy at yahoo.co.uk Mon Jul 12 01:03:52 2010 From: breamoreboy at yahoo.co.uk (Mark Lawrence) Date: Mon, 12 Jul 2010 00:03:52 +0100 Subject: [Idle-dev] [Python-Dev] Removing IDLE from the standard library In-Reply-To: References: <4C3A0F85.1090404@v.loewis.de> Message-ID: 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. From glyph at twistedmatrix.com Mon Jul 12 01:43:06 2010 From: glyph at twistedmatrix.com (Glyph Lefkowitz) Date: Sun, 11 Jul 2010 19:43:06 -0400 Subject: [Idle-dev] [Python-Dev] Removing IDLE from the standard library In-Reply-To: <4C3A1938.4020304@v.loewis.de> References: <4C3A0F85.1090404@v.loewis.de> <4C3A1938.4020304@v.loewis.de> Message-ID: <1E32216D-8C3A-4BD8-8E5A-127E98B863AB@twistedmatrix.com> 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 , 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). 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. and 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, 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.) -------------- next part -------------- An HTML attachment was scrubbed... URL: From glyph at twistedmatrix.com Mon Jul 12 01:46:16 2010 From: glyph at twistedmatrix.com (Glyph Lefkowitz) Date: Sun, 11 Jul 2010 19:46:16 -0400 Subject: [Idle-dev] [Python-Dev] Removing IDLE from the standard library In-Reply-To: References: <4C3A0F85.1090404@v.loewis.de> Message-ID: <5896CB82-8A76-4D64-B665-EB16DC2C4A9A@twistedmatrix.com> 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at holdenweb.com Mon Jul 12 01:53:39 2010 From: steve at holdenweb.com (Steve Holden) Date: Sun, 11 Jul 2010 19:53:39 -0400 Subject: [Idle-dev] Removing IDLE from the standard library In-Reply-To: References: Message-ID: <4C3A5983.3010002@holdenweb.com> Stephen Hansen wrote: > On Sat, Jul 10, 2010 at 9:23 PM, Guilherme Polo > 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/ From tjreedy at udel.edu Mon Jul 12 04:14:51 2010 From: tjreedy at udel.edu (Terry Reedy) Date: Sun, 11 Jul 2010 22:14:51 -0400 Subject: [Idle-dev] [Python-Dev] Removing IDLE from the standard library In-Reply-To: References: <4C3A0F85.1090404@v.loewis.de> <11989_1278874767_o6BIxON2026376_EA883BC9-5C6B-4444-B0D7-1BA51815328F@twistedmatrix.com> <4C3A415F.6050709@v.loewis.de> Message-ID: On 7/11/2010 6:29 PM, Guilherme Polo wrote: > I think Martin has always supported me in some way and I really > appreciate that. But, maybe because I won commit privileges solely > based on GSoC work, I felt other developers wouldn't approve my > commits without previous discussion and that is the major reason for > not committing most of my patches. I do not currently have commit privileges, and do not especially want the mechanical part of such. As I said in another post, I do not have the development environment needed, being quite happy with repeated edit/run cycles in IDLE for my real work. However, for the same reason, I am anxious If I had IDLE Commit Authorization privileges, would you feel more comfortable making commits that I approve of? -- Terry Jan Reedy From tjreedy at udel.edu Mon Jul 12 04:26:01 2010 From: tjreedy at udel.edu (Terry Reedy) Date: Sun, 11 Jul 2010 22:26:01 -0400 Subject: [Idle-dev] [Python-Dev] Removing IDLE from the standard library In-Reply-To: References: <4C3A0F85.1090404@v.loewis.de> <11989_1278874767_o6BIxON2026376_EA883BC9-5C6B-4444-B0D7-1BA51815328F@twistedmatrix.com> <4C3A415F.6050709@v.loewis.de> Message-ID: On 7/11/2010 6:39 PM, Tal Einat wrote: Tal, there is nothing to get supporters to appear out of the woodwork like proposing to trash something ;-). I am pretty sure that your post will result in more action. I notice that an IDLE issue I submitted yesterday is not auto-assigned to anyone, so any developer is free to grab it. > FWIW this is why I started IDLE-Spoon (well, continued Noam Raphael's > project of the same name, in a sense). The idea was to have a fork of > IDLE with new features which need to be tried out by "beta testers" to > iron out all of the glitches before making it into the main version, > like IDLE-fork back in the beginning of the decade. However I have > utterly failed in promoting this project and getting "beta testers" on > board, at least partially due to the lack of interest from the > community (and admittedly my lack of PR skills). I have no memory of hearing about this. If you want, send me a zip that I can unpack and run on Windows, and instructions about what new feature to test. -- Terry Jan Reedy From miki.tebeka at gmail.com Sun Jul 11 03:51:04 2010 From: miki.tebeka at gmail.com (Miki Tebeka) Date: Sat, 10 Jul 2010 18:51:04 -0700 Subject: [Idle-dev] [Python-Dev] Removing IDLE from the standard library In-Reply-To: References: Message-ID: 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"? All the best, -- Miki From raymond.hettinger at gmail.com Sun Jul 11 06:29:52 2010 From: raymond.hettinger at gmail.com (Raymond Hettinger) Date: Sat, 10 Jul 2010 21:29:52 -0700 Subject: [Idle-dev] [Python-Dev] Removing IDLE from the standard library In-Reply-To: References: Message-ID: On Jul 10, 2010, at 9:23 PM, Guilherme Polo wrote: > 2010/7/10 Miki Tebeka : >> 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 From apt.shansen at gmail.com Sun Jul 11 08:01:16 2010 From: apt.shansen at gmail.com (Stephen Hansen) Date: Sat, 10 Jul 2010 23:01:16 -0700 Subject: [Idle-dev] [Python-Dev] Removing IDLE from the standard library In-Reply-To: References: Message-ID: On Sat, Jul 10, 2010 at 9:23 PM, Guilherme Polo 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. >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. --Stephen -------------- next part -------------- An HTML attachment was scrubbed... URL: From list at qtrac.plus.com Sun Jul 11 09:30:02 2010 From: list at qtrac.plus.com (Mark Summerfield) Date: Sun, 11 Jul 2010 08:30:02 +0100 Subject: [Idle-dev] [Python-Dev] Removing IDLE from the standard library In-Reply-To: <20F50EEB-2336-41D9-B530-EC3A4EE7A46E@mac.com> References: <20F50EEB-2336-41D9-B530-EC3A4EE7A46E@mac.com> Message-ID: <201007110830.02802.list@qtrac.plus.com> 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 From janssen at parc.com Sun Jul 11 19:35:16 2010 From: janssen at parc.com (Bill Janssen) Date: Sun, 11 Jul 2010 10:35:16 PDT Subject: [Idle-dev] [Python-Dev] Removing IDLE from the standard library In-Reply-To: References: Message-ID: <9773.1278869716@parc.com> Tal Einat 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/e14b647243ca5b66). For David and other teachers, there are plenty of alternative IDEs, outlined at http://wiki.python.org/moin/IntegratedDevelopmentEnvironments. Bill From martin at v.loewis.de Sun Jul 11 20:37:57 2010 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Sun, 11 Jul 2010 20:37:57 +0200 Subject: [Idle-dev] [Python-Dev] Removing IDLE from the standard library In-Reply-To: References: Message-ID: <4C3A0F85.1090404@v.loewis.de> > 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 From martin at v.loewis.de Sun Jul 11 21:19:20 2010 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Sun, 11 Jul 2010 21:19:20 +0200 Subject: [Idle-dev] [Python-Dev] Removing IDLE from the standard library In-Reply-To: References: <4C3A0F85.1090404@v.loewis.de> Message-ID: <4C3A1938.4020304@v.loewis.de> > (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 From basherwo at ncsu.edu Sun Jul 11 23:58:32 2010 From: basherwo at ncsu.edu (Bruce Sherwood) Date: Sun, 11 Jul 2010 15:58:32 -0600 Subject: [Idle-dev] [Python-Dev] Removing IDLE from the standard library In-Reply-To: <11989_1278874767_o6BIxON2026376_EA883BC9-5C6B-4444-B0D7-1BA51815328F@twistedmatrix.com> References: <4C3A0F85.1090404@v.loewis.de> <11989_1278874767_o6BIxON2026376_EA883BC9-5C6B-4444-B0D7-1BA51815328F@twistedmatrix.com> Message-ID: Perhaps there are two separable issues. Many of us see it as extremely important that some IDLE be part of the standard Python distribution ("batteries included"), for the reasons that several people have given. However, there is merit to the suggestion to have an active separate development, with the understanding that periodically this separate development is a candidate for inclusion in the standard distribution, replacing whatever IDLE had been there. In the 2009 Google Summer of Code I was the mentor for a Brazilian student, Guilherme Polo, who completed and extended important improvements to IDLE made during the previous year by David Scherer. Given the somewhat official nature of this work, I assumed that these needed improvements would make it into the standard distribution, but as far as I know that hasn't happened. It would seem that if even this "sponsored" project didn't impact the standard Python distribution, something is broken in the procedures, and probably what is needed is, as Guido says, that someone be given the authority to get improvements to IDLE into the standard distribution. Making a significant change to the update procedures is clearly needed. Even if this needed change is made, there is also merit to Tai's suggestion of creating a separate project, to encourage developers like him to work together to improve IDLE, without having as a first priority to worry about getting it into the standard distribution, but with the clear understanding that this is the place to go for improvements to migrate into the standard distribution. Bruce Sherwood P.S. I'll add that IDLE has been EXTREMELY important for a large population of relatively casual users of Python, the thousands of science and engineering university students enrolled in the "Matter & Interactions" intro physics curriculum developed by Ruth Chabay and me ( matterandinteractions.org). A major feature of this curriculum is a serious introduction to computational modeling, in which students write short Python programs to model physical systems. Computational modeling is now central to all of science and engineering but alas has not made its way into undergraduate curricula in an institutionalized way. A big difficulty is that students come to college knowledgeable about all aspects of computers save one: programming. So the programming environment has to be exceptionally easy to learn and use. Python itself has the necessary properties, and Python+Visual (called VPython, vpython.org) lets the students focus on the physics while VPython generates real-time navigable 3D animations of the computational models, as a side effect of the computational code. IDLE has proved to be the right editing tool for this population, as essentially nothing needs to be learned, and there is near-instantaneous edit/run transitions which encourage rapid testing. In a physics course we have to focus on strict minimalism as far as the programming is concerned. We teach a bare minimum of needed concepts; for example, we introduce while loops but not for loops. We cannot afford to teach about a professional IDE; IDLE is fine and has worked well for us. (We're currently bundling with VPython the Scherer/Polo version of IDLE, which for reasons of clarity we're calling VIDLE.) A final personal note is that while I use Eclipse for working on the Visual module, which is written in C++, I find VIDLE a delightful environment for developing Python programs for physics education. -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin at v.loewis.de Mon Jul 12 00:10:39 2010 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Mon, 12 Jul 2010 00:10:39 +0200 Subject: [Idle-dev] [Python-Dev] Removing IDLE from the standard library In-Reply-To: References: <4C3A0F85.1090404@v.loewis.de> <11989_1278874767_o6BIxON2026376_EA883BC9-5C6B-4444-B0D7-1BA51815328F@twistedmatrix.com> Message-ID: <4C3A415F.6050709@v.loewis.de> > In the 2009 Google Summer of Code I was the mentor for a Brazilian > student, Guilherme Polo, who completed and extended important > improvements to IDLE made during the previous year by David Scherer. > Given the somewhat official nature of this work, I assumed that these > needed improvements would make it into the standard distribution, but as > far as I know that hasn't happened. It would seem that if even this > "sponsored" project didn't impact the standard Python distribution, > something is broken in the procedures, and probably what is needed is, > as Guido says, that someone be given the authority to get improvements > to IDLE into the standard distribution. Making a significant change to > the update procedures is clearly needed. I don't think so; instead, the perception of authority needs to be adjusted (in the specific case). Guilherme could have committed these changes, but, for whatever reason, decided not to. Nor did his direct mentor (i.e. you) tell him to commit the changes, and neither did I. > Even if this needed change is made, there is also merit to Tai's > suggestion of creating a separate project, to encourage developers like > him to work together to improve IDLE, without having as a first priority > to worry about getting it into the standard distribution, but with the > clear understanding that this is the place to go for improvements to > migrate into the standard distribution. Again, Guilherme could commit his changes any time. Regards, Martin From martin at v.loewis.de Mon Jul 12 00:28:58 2010 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Mon, 12 Jul 2010 00:28:58 +0200 Subject: [Idle-dev] [Python-Dev] Removing IDLE from the standard library In-Reply-To: References: <4C3A0F85.1090404@v.loewis.de> Message-ID: <4C3A45AA.3050501@v.loewis.de> > 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 From martin at v.loewis.de Mon Jul 12 00:36:33 2010 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Mon, 12 Jul 2010 00:36:33 +0200 Subject: [Idle-dev] [Python-Dev] Removing IDLE from the standard library In-Reply-To: References: <4C3A0F85.1090404@v.loewis.de> <11989_1278874767_o6BIxON2026376_EA883BC9-5C6B-4444-B0D7-1BA51815328F@twistedmatrix.com> <4C3A415F.6050709@v.loewis.de> Message-ID: <4C3A4771.5090501@v.loewis.de> > I think Martin has always supported me in some way and I really > appreciate that. But, maybe because I won commit privileges solely > based on GSoC work, I felt other developers wouldn't approve my > commits without previous discussion and that is the major reason for > not committing most of my patches. I'm not blaming you for that; I can fully understand how you feel and how things came about. I was just refuting the claim that something was fundamentally wrong, when, among us three, there was just somebody failing to say "go ahead" (and I'd like to stress that *either* of us three could have said that). So: go ahead. I won't have the time to review your changes in detail, and nobody else will, so just put them in, and we wait for people to complain (in which case I'd hope that you would be around to respond quickly - as you did in the past). If there is also Tk patches involved, please do have them reviewed, though. Regards, Martin From martin at v.loewis.de Mon Jul 12 00:41:50 2010 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Mon, 12 Jul 2010 00:41:50 +0200 Subject: [Idle-dev] [Python-Dev] Removing IDLE from the standard library In-Reply-To: References: <217B30F6-06FE-4237-90C2-540CD6BB6A28@twistedmatrix.com> Message-ID: <4C3A48AE.9010707@v.loewis.de> > 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 From martin at v.loewis.de Mon Jul 12 00:44:14 2010 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Mon, 12 Jul 2010 00:44:14 +0200 Subject: [Idle-dev] [Python-Dev] Removing IDLE from the standard library In-Reply-To: References: <4C3A0F85.1090404@v.loewis.de> <11989_1278874767_o6BIxON2026376_EA883BC9-5C6B-4444-B0D7-1BA51815328F@twistedmatrix.com> <4C3A415F.6050709@v.loewis.de> Message-ID: <4C3A493E.8090308@v.loewis.de> > FWIW this is why I started IDLE-Spoon (well, continued Noam Raphael's > project of the same name, in a sense). The idea was to have a fork of > IDLE with new features which need to be tried out by "beta testers" to > iron out all of the glitches before making it into the main version, > like IDLE-fork back in the beginning of the decade. However I have > utterly failed in promoting this project and getting "beta testers" on > board, at least partially due to the lack of interest from the > community (and admittedly my lack of PR skills). I think such a thing must inherently fail - precisely for these reasons. It's much better to release proposed new features along with Python, and wait for feedback. Users won't start trying things out until after the release. This is a general problem, and lead Barry Warsaw to believe that "release candidates" are an utter waste of time. Regards, Martin From benjamin at python.org Mon Jul 12 01:08:20 2010 From: benjamin at python.org (Benjamin Peterson) Date: Sun, 11 Jul 2010 18:08:20 -0500 Subject: [Idle-dev] [Python-Dev] Removing IDLE from the standard library In-Reply-To: References: <4C3A0F85.1090404@v.loewis.de> Message-ID: 2010/7/11 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 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 From benjamin at python.org Mon Jul 12 01:14:38 2010 From: benjamin at python.org (Benjamin Peterson) Date: Sun, 11 Jul 2010 18:14:38 -0500 Subject: [Idle-dev] [Python-Dev] Removing IDLE from the standard library In-Reply-To: References: <4C3A0F85.1090404@v.loewis.de> Message-ID: 2010/7/11 Mark Lawrence : > 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 From basherwo at ncsu.edu Mon Jul 12 03:43:00 2010 From: basherwo at ncsu.edu (Bruce Sherwood) Date: Sun, 11 Jul 2010 19:43:00 -0600 Subject: [Idle-dev] Removing IDLE from the standard library In-Reply-To: <29559_1278893635_o6C0DslL000282_4C3A5983.3010002@holdenweb.com> References: <29559_1278893635_o6C0DslL000282_4C3A5983.3010002@holdenweb.com> Message-ID: On the notion that IDLE is fatally flawed and is driving away potential users of Python (to put the statements in their most extreme form): It seems that there are (at least) two very different communities people have in mind. I can appreciate that highly expert programmers may find IDLE insufficient for their needs, and it might even be the case that these people should be advised not to even try IDLE. But I want to stress as strongly as possible that for a very large community of nonexpert users of Python, IDLE has been extremely important and works very well for their purposes. Editing is pretty much like what they're already used to in word processors, which is certainly not the case with professional tools such as vim or Emacs. That said, yes, there are some significant deficiencies with the current IDLE (which is why there's a VIDLE, for instance). I'm very glad to hear from Martin that Guilherme is free to commit his important bug fixes and improvements. I'm afraid that neither Guilherme nor I understood the procedures and thought that we had to wait for others to act. Bruce Sherwood -------------- next part -------------- An HTML attachment was scrubbed... URL: From ronaldoussoren at mac.com Mon Jul 12 07:52:48 2010 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Mon, 12 Jul 2010 07:52:48 +0200 Subject: [Idle-dev] [Python-Dev] Removing IDLE from the standard library In-Reply-To: <9773.1278869716@parc.com> References: <9773.1278869716@parc.com> Message-ID: <612FF368-08DD-4A7B-AD20-5C543E418259@mac.com> On 11 Jul, 2010, at 19:35, Bill Janssen wrote: > Tal Einat 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/e14b647243ca5b66). 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3567 bytes Desc: not available URL: From apt.shansen at gmail.com Mon Jul 12 08:24:38 2010 From: apt.shansen at gmail.com (Stephen Hansen) Date: Sun, 11 Jul 2010 23:24:38 -0700 Subject: [Idle-dev] [Python-Dev] Removing IDLE from the standard library In-Reply-To: <4C3A5983.3010002@holdenweb.com> References: <4C3A5983.3010002@holdenweb.com> Message-ID: On Sun, Jul 11, 2010 at 4:53 PM, Steve Holden wrote: > Stephen Hansen wrote: > > On Sat, Jul 10, 2010 at 9:23 PM, Guilherme Polo > > 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From ronaldoussoren at mac.com Mon Jul 12 07:50:47 2010 From: ronaldoussoren at mac.com (Ronald Oussoren) Date: Mon, 12 Jul 2010 07:50:47 +0200 Subject: [Idle-dev] Removing IDLE from the standard library In-Reply-To: <4C39C626.40400@codebykevin.com> References: <7EF8C99A-4163-461A-922B-1FF3003D89E2@mac.com> <4C39C626.40400@codebykevin.com> Message-ID: 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 3567 bytes Desc: not available URL: From kbk at shore.net Mon Jul 12 11:20:49 2010 From: kbk at shore.net (Kurt B. Kaiser) Date: Mon, 12 Jul 2010 05:20:49 -0400 Subject: [Idle-dev] Removing IDLE from the standard library In-Reply-To: (Bruce Sherwood's message of "Sun, 11 Jul 2010 19:43:00 -0600") References: <29559_1278893635_o6C0DslL000282_4C3A5983.3010002@holdenweb.com> Message-ID: <87sk3p2gzy.fsf@hydra.hampton.thirdcreek.com> On Sun, Jul 11 2010, Bruce Sherwood wrote: > On the notion that IDLE is fatally flawed and is driving away > potential users of Python (to put the statements in their most extreme > form): > > It seems that there are (at least) two very different communities > people have in mind. I can appreciate that highly expert programmers > may find IDLE insufficient for their needs, and it might even be the > case that these people should be advised not to even try IDLE. But I > want to stress as strongly as possible that for a very large community > of nonexpert users of Python, IDLE has been extremely important and > works very well for their purposes. Editing is pretty much like what > they're already used to in word processors, which is certainly not the > case with professional tools such as vim or Emacs. Particularly on Windows, there is an expectation that a contemporary programming language comes with a GUI. Using the Windows Python shell isn't very satisfactory, largely because of the poor file handling capability in that environment. IDLE provides a simple solution, suitable for beginners as well as experts. It provides one-keystroke save/run in a fresh environment not associated with the GUI. I have run IDLE inside IDLE (though I'm not positive that will work right now). How many IDEs can do that? I've tried to channel Guido, and my general approach has been to provide as much functionality as needed, but to hide the more advanced features to avoid clutter. When the 'experts' need them, they will find them. I'm mystified about the comments that the GUI is ugly. It is minimal. On XP, it looks exactly like an XP window with a simple menubar. Those who haven't looked at it for awhile may not be aware of the recent advances made by Tk in native look and feel. What is ugly? And IDLE is cross-platform. There are perhaps deficiencies on the Mac, but Ron has made good progress. I haven't been able to come up with a Mac yet, so I can't really comment. IDLE works on 2.7 and 3.x. Running IDLE on the trunk is a decent test of Python and tkinter during development. It seems that people who do Scheme write Scheme implementations, while people who do Python write IDEs :-) Usually, they keep adding features and buttons until it looks like Eclipse. That's fine. But why turn IDLE into another example of that style and diminish diversity in doing so? On a netbook, screen space is at a premium, and a simple interface has advantages. There are many IDEs listed on the wiki if people are looking for the more complex style, but I'd suggest that they aren't appropriate for beginners. And by beginners, I include elementary school students. IDLE works with "extensions". Plug-ins, if you will. The Option dialog needs enhancement to support extension selection, and I believe there is a patch to do that. More extensions would be a good thing. The .idlerc directory determines IDLE's configuration, including the help source urls available on the Help menu. By downloading .idlerc or via indirection, a student environment can be set up including the day's lesson and which extensions are activated. Call tips and method name completion can be "hidden" by increasing the time delay before they pop up. > That said, yes, there are some significant deficiencies with the > current IDLE (which is why there's a VIDLE, for instance). I'm very > glad to hear from Martin that Guilherme is free to commit his > important bug fixes and improvements. I'm afraid that neither > Guilherme nor I understood the procedures and thought that we had to > wait for others to act. Tal has made a couple of comments about not being able to run multiple IDLEs at the same time, and he mentions http://bugs.python.org/issue1529142 This bug has been closed for over a year, and you can run as many IDLEs as you like. You can run 2.7 and 3.x at the same time. I would have expected Tal to know that. Also, the current right click edit action on Windows is to only open an edit window; no shell. And it uses the subprocess! So, some of the comments on this thread are not up to date. The reason that bug languished for two years was because first, it was a bit of a hack, and second, Windows was problematic in that it reused sockets and often left zombie subprocesses behind which couldn't be killed except with the task manager. This causes real problems with students - they lose confidence in the tool. Scherer and Weeble put together a patch using ephemeral ports which nailed the problem, and I checked it in right away and forward/backported it. As I recollect, much of what Scherer did in VIDLE related to running multiple IDLE copies. For that reason, the VIDLE changes have to be evaluated carefully to determine what has already been incorporated. I believe I added a couple of his smaller changes, also. Bruce, speaking of Dave Scherer, we've been trying to get a Python Contributor Agreement from him. Is that something you can help us with? -- KBK From solipsis at pitrou.net Mon Jul 12 12:10:40 2010 From: solipsis at pitrou.net (Antoine Pitrou) Date: Mon, 12 Jul 2010 12:10:40 +0200 Subject: [Idle-dev] Removing IDLE from the standard library References: <29559_1278893635_o6C0DslL000282_4C3A5983.3010002@holdenweb.com> <87sk3p2gzy.fsf@hydra.hampton.thirdcreek.com> Message-ID: <20100712121040.41f16654@pitrou.net> On Mon, 12 Jul 2010 05:20:49 -0400 "Kurt B. Kaiser" wrote: > > I'm mystified about the comments that the GUI is ugly. It is minimal. > On XP, it looks exactly like an XP window with a simple menubar. Those > who haven't looked at it for awhile may not be aware of the recent > advances made by Tk in native look and feel. What is ugly? Ok, I've just tried IDLE (on py3k) for the first time in years. Under Linux, the look is ugly and outdated; it uses some kind of Motif-like widgets. Usability is inconsistent with the rest of the desktop, and looks generally subpar (for example, you have to click on a menu to open it; the file open dialog is antiquated and doesn't allow me to use keyboard shortcuts). The editor looks decent, though there doesn't seem to be a simple (e.g. Shift+Tab) way of unindenting a block of code. Regards Antoine. From solipsis at pitrou.net Mon Jul 12 12:21:08 2010 From: solipsis at pitrou.net (Antoine Pitrou) Date: Mon, 12 Jul 2010 12:21:08 +0200 Subject: [Idle-dev] Removing IDLE from the standard library References: <29559_1278893635_o6C0DslL000282_4C3A5983.3010002@holdenweb.com> <87sk3p2gzy.fsf@hydra.hampton.thirdcreek.com> <20100712121040.41f16654@pitrou.net> Message-ID: <20100712122108.62fa0f3c@pitrou.net> After a few keystrokes in the interactive interpreter, I got the following traceback: Traceback (most recent call last): File "Lib/idlelib/idle.py", line 11, in idlelib.PyShell.main() File "/home/antoine/py3k/__svn__/Lib/idlelib/PyShell.py", line 1420, in main root.mainloop() File "/home/antoine/py3k/__svn__/Lib/tkinter/__init__.py", line 1009, in mainloop self.tk.mainloop(n) UnicodeDecodeError: 'utf8' codec can't decode byte 0xc0 in position 0: invalid start byte The keystrokes were ['d', 'i', Ctrl+Space], which briefly displayed the completion popup before crashing. Regards Antoine. From taleinat at gmail.com Mon Jul 12 12:52:31 2010 From: taleinat at gmail.com (Tal Einat) Date: Mon, 12 Jul 2010 13:52:31 +0300 Subject: [Idle-dev] Removing IDLE from the standard library In-Reply-To: <87sk3p2gzy.fsf@hydra.hampton.thirdcreek.com> References: <29559_1278893635_o6C0DslL000282_4C3A5983.3010002@holdenweb.com> <87sk3p2gzy.fsf@hydra.hampton.thirdcreek.com> Message-ID: Hi Kurt, I'm glad you've joined this discussion. My point is that whatever the reason, for the past five years (at least) nearly every issue related to IDLE has taken years to be resolved, and many have still not been resolved. As a result the current state of IDLE is quite poor. To be perfectly clear, I'm am not blaming anyone for this. I just think this is something the development community should be more aware of and decide how to deal with. On Mon, Jul 12, 2010 at 12:20 PM, Kurt B. Kaiser wrote: > Particularly on Windows, there is an expectation that a contemporary > programming language comes with a GUI. ?Using the Windows Python shell > isn't very satisfactory, largely because of the poor file handling > capability in that environment. ?IDLE provides a simple solution, > suitable for beginners as well as experts. ?It provides one-keystroke > save/run in a fresh environment not associated with the GUI. ?I have run > IDLE inside IDLE (though I'm not positive that will work right now). > How many IDEs can do that? [snip] > On a netbook, screen space is at a premium, and a simple interface has > advantages. ?There are many IDEs listed on the wiki if people are > looking for the more complex style, but I'd suggest that they aren't > appropriate for beginners. ?And by beginners, I include elementary > school students. I agree that IDLE is great specifically thanks to its simplicity, and should be kept simple. I think something like IDLE can be great for teaching and learning Python (and other uses as well) and has a place in the stdlib. I'm simply not sure if IDLE in its current state is fit for this purpose. > I'm mystified about the comments that the GUI is ugly. It is minimal. > On XP, it looks exactly like an XP window with a simple menubar. Those > who haven't looked at it for awhile may not be aware of the recent > advances made by Tk in native look and feel. What is ugly? IDLE may be somewhat close to looking like a native application, but it is not quite there. Some examples: * Users expect to be able to copy/paste using the mouse via the right-click context menu, which is impossible in IDLE (in both shell and editor windows). * The selection jumping to the end of the line unexpectedly doesn't happen in any other GUI text editor. * The config dialog looks archaic. As for the native look&feel, this has still not been integrated into IDLE, though it seems now it will happen soon. This has already been discussed here. > IDLE works with "extensions". ?Plug-ins, if you will. ?The Option dialog > needs enhancement to support extension selection, and I believe there is > a patch to do that. ?More extensions would be a good thing. IDLE extensions are a pain to work with and badly supported. Installing an extension requires manually placing it in the idlelib directory and manually adding its config options to a certain text file in that directory. In practice nobody ever takes the effort to try installing an IDLE extension, such as my SearchBar extension. There has been discussion on improving this situation, but again this never actually happened. I tried to move this along with a patch which adds an extension config dialog, which has been sitting in the issue tracker ignored for two years. > Tal has made a couple of comments about not being able to run multiple > IDLEs at the same time, and he mentions > > http://bugs.python.org/issue1529142 > > This bug has been closed for over a year, and you can run as many IDLEs > as you like. ?You can run 2.7 and 3.x at the same time. ?I would have > expected Tal to know that. I clearly mentioned that as an example of a fix for a major usability issue which took three years to resolve after a workaround was first posted. It is worth noting that most people still don't use the versions of Python (and IDLE) where this fix has been integrated. > The reason that bug languished for two years was because first, it was a > bit of a hack, and second, Windows was problematic in that it reused > sockets and often left zombie subprocesses behind which couldn't be > killed except with the task manager. ?This causes real problems with > students - they lose confidence in the tool. > > Scherer and Weeble put together a patch using ephemeral ports which > nailed the problem, and I checked it in right away and > forward/backported it. True, but it took three whole years for this to happen. And this is for a glaring, annoying and limiting issue that nearly every user of IDLE has encountered. From taleinat at gmail.com Mon Jul 12 13:01:54 2010 From: taleinat at gmail.com (Tal Einat) Date: Mon, 12 Jul 2010 14:01:54 +0300 Subject: [Idle-dev] [Python-Dev] Removing IDLE from the standard library In-Reply-To: <4C3A48AE.9010707@v.loewis.de> References: <217B30F6-06FE-4237-90C2-540CD6BB6A28@twistedmatrix.com> <4C3A48AE.9010707@v.loewis.de> Message-ID: On Mon, Jul 12, 2010 at 1:41 AM, "Martin v. L?wis" 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 From taleinat at gmail.com Mon Jul 12 13:07:05 2010 From: taleinat at gmail.com (Tal Einat) Date: Mon, 12 Jul 2010 14:07:05 +0300 Subject: [Idle-dev] [Python-Dev] Removing IDLE from the standard library In-Reply-To: <4C3A493E.8090308@v.loewis.de> References: <4C3A0F85.1090404@v.loewis.de> <11989_1278874767_o6BIxON2026376_EA883BC9-5C6B-4444-B0D7-1BA51815328F@twistedmatrix.com> <4C3A415F.6050709@v.loewis.de> <4C3A493E.8090308@v.loewis.de> Message-ID: On Mon, Jul 12, 2010 at 1:44 AM, "Martin v. L?wis" wrote: >> FWIW this is why I started IDLE-Spoon (well, continued Noam Raphael's >> project of the same name, in a sense). The idea was to have a fork of >> IDLE with new features which need to be tried out by "beta testers" to >> iron out all of the glitches before making it into the main version, >> like IDLE-fork back in the beginning of the decade. However I have >> utterly failed in promoting this project and getting "beta testers" on >> board, at least partially due to the lack of interest from the >> community (and admittedly my lack of PR skills). > > I think such a thing must inherently fail - precisely for these reasons. > > It's much better to release proposed new features along with Python, > and wait for feedback. Users won't start trying things out until after > the release. This is a general problem, and lead Barry Warsaw to believe > that "release candidates" are an utter waste of time. That's debatable, and I disagree. IDLE-fork was a great success, for example. If IDLE actually had many users today, certainly some of them would be interested in trying out a version with usability fixes and improvements. Waiting for a new release of Python can take over a year. Furthermore, backwards compatibility issues and support by third party libraries can delay migration to a newer version of Python even further. - Tal Einat From kw at codebykevin.com Mon Jul 12 14:41:37 2010 From: kw at codebykevin.com (Kevin Walzer) Date: Mon, 12 Jul 2010 08:41:37 -0400 Subject: [Idle-dev] Removing IDLE from the standard library In-Reply-To: References: <7EF8C99A-4163-461A-922B-1FF3003D89E2@mac.com> <4C39C626.40400@codebykevin.com> Message-ID: <4C3B0D81.7070803@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 From motoom at xs4all.nl Mon Jul 12 16:16:11 2010 From: motoom at xs4all.nl (Michiel Overtoom) Date: Mon, 12 Jul 2010 16:16:11 +0200 Subject: [Idle-dev] Removing IDLE from the standard library In-Reply-To: References: Message-ID: <4C3B23AB.3000108@xs4all.nl> 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, From kw at codebykevin.com Mon Jul 12 16:34:50 2010 From: kw at codebykevin.com (Kevin Walzer) Date: Mon, 12 Jul 2010 10:34:50 -0400 Subject: [Idle-dev] Removing IDLE from the standard library In-Reply-To: <4C3B23AB.3000108@xs4all.nl> References: <4C3B23AB.3000108@xs4all.nl> Message-ID: <4C3B280A.90102@codebykevin.com> 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 From kbk at shore.net Mon Jul 12 17:11:23 2010 From: kbk at shore.net (Kurt B. Kaiser) Date: Mon, 12 Jul 2010 11:11:23 -0400 Subject: [Idle-dev] [Python-Dev] Removing IDLE from the standard library In-Reply-To: (Tal Einat's message of "Mon, 12 Jul 2010 14:07:05 +0300") References: <4C3A0F85.1090404@v.loewis.de> <11989_1278874767_o6BIxON2026376_EA883BC9-5C6B-4444-B0D7-1BA51815328F@twistedmatrix.com> <4C3A415F.6050709@v.loewis.de> <4C3A493E.8090308@v.loewis.de> Message-ID: <878w5g3fc4.fsf@hydra.hampton.thirdcreek.com> On Mon, Jul 12 2010, Tal Einat wrote: > On Mon, Jul 12, 2010 at 1:44 AM, "Martin v. L?wis" wrote: >>> FWIW this is why I started IDLE-Spoon (well, continued Noam Raphael's >>> project of the same name, in a sense). The idea was to have a fork of >>> IDLE with new features which need to be tried out by "beta testers" to >>> iron out all of the glitches before making it into the main version, >>> like IDLE-fork back in the beginning of the decade. However I have >>> utterly failed in promoting this project and getting "beta testers" on >>> board, at least partially due to the lack of interest from the >>> community (and admittedly my lack of PR skills). >> >> I think such a thing must inherently fail - precisely for these reasons. >> >> It's much better to release proposed new features along with Python, >> and wait for feedback. Users won't start trying things out until after >> the release. This is a general problem, and lead Barry Warsaw to believe >> that "release candidates" are an utter waste of time. > > That's debatable, and I disagree. IDLE-fork was a great success, for example. We had major contributions from David Scherer, Guido, and Stephen Gava. But a key factor in its success was that I took it upon myself to keep IDLEfork sync'd with core IDLE using a cvs vendor branch and frequent merges. Once the project was completed, I arranged with SF to move the IDLEfork repository, including history, back into Python. This was not done with Noam's branch. As a result, it gradually drifted to the point where it became essentially unmergable. Once we switch to Hg, we should be able to use distributed vc and topic branches to facilitate community participation without the need for a separate project. None of this is automatic, of course, it requires diligence, planning, and clean topic patches. > > If IDLE actually had many users today, certainly some of them would be > interested in trying out a version with usability fixes and > improvements. Waiting for a new release of Python can take over a > year. Furthermore, backwards compatibility issues and support by third > party libraries can delay migration to a newer version of Python even > further. There's no reason why we couldn't release interim IDLE testing packages from somewhere other than python.org (for those that don't want to track IDLE's Hg repo). To do this successfully, we would need to avoid using new Python features being introduced during that development cycle, i.e. IDLE would be compatible with the previous Python release. -- KBK From basherwo at ncsu.edu Mon Jul 12 17:12:51 2010 From: basherwo at ncsu.edu (Bruce Sherwood) Date: Mon, 12 Jul 2010 09:12:51 -0600 Subject: [Idle-dev] Removing IDLE from the standard library In-Reply-To: <87sk3p2gzy.fsf@hydra.hampton.thirdcreek.com> References: <29559_1278893635_o6C0DslL000282_4C3A5983.3010002@holdenweb.com> <87sk3p2gzy.fsf@hydra.hampton.thirdcreek.com> Message-ID: On Mon, Jul 12, 2010 at 3:20 AM, Kurt B. Kaiser wrote: > > > As I recollect, much of what Scherer did in VIDLE related to running > multiple IDLE copies. > > For that reason, the VIDLE changes have to be evaluated carefully to > determine what has already been incorporated. I believe I added a > couple of his smaller changes, also. > > Bruce, speaking of Dave Scherer, we've been trying to get a Python > Contributor Agreement from him. Is that something you can help us with? > > -- > KBK > I don't recall that VIDLE has anything to do with running multiple IDLE copies. What's in VIDLE is a lot of bug fixes and some improvements. For example, you can configure it to not require having to save a file, which makes it as easy to use for quick testing as the shell. Another improvement, of high importance for our physics students and other novice programmers, is to bring an error display forward. Many students fill the screen with the edit window and the error message could be hidden, leaving them puzzled as to why their program wasn't running. Stuff like that, all aimed at issues we had seen with a large population of science and engineering students. I'll say again that IDLE/VIDLE is an excellent environment for novices. Issues identified here about look and feel etc. have just not been of any importance in that context. If you'll send me what you want from Scherer, I can contact him. Bruce Sherwood -------------- next part -------------- An HTML attachment was scrubbed... URL: From taleinat at gmail.com Mon Jul 12 17:14:16 2010 From: taleinat at gmail.com (Tal Einat) Date: Mon, 12 Jul 2010 18:14:16 +0300 Subject: [Idle-dev] Removing IDLE from the standard library In-Reply-To: <87sk3p2gzy.fsf@hydra.hampton.thirdcreek.com> References: <29559_1278893635_o6C0DslL000282_4C3A5983.3010002@holdenweb.com> <87sk3p2gzy.fsf@hydra.hampton.thirdcreek.com> Message-ID: Kurt B. Kaiser wrote: >> 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, you've got some catching up to do, yourself. Tile went into Tk in > 8.5, two years ago. I was referring to the integration of the new ttk widgets into IDLE, which still hasn't happened despite two years having gone by. Sorry for not being clear on that point. - Tal Einat From janssen at parc.com Mon Jul 12 17:44:10 2010 From: janssen at parc.com (Bill Janssen) Date: Mon, 12 Jul 2010 08:44:10 PDT Subject: [Idle-dev] [Python-Dev] Removing IDLE from the standard library In-Reply-To: References: <4C3A5983.3010002@holdenweb.com> Message-ID: <86474.1278949450@parc.com> Stephen Hansen wrote: > On Sun, Jul 11, 2010 at 4:53 PM, Steve Holden wrote: > > > Stephen Hansen wrote: > > > On Sat, Jul 10, 2010 at 9:23 PM, Guilherme Polo > > > 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 From rrr at ronadam.com Mon Jul 12 00:38:02 2010 From: rrr at ronadam.com (Ron Adam) Date: Sun, 11 Jul 2010 17:38:02 -0500 Subject: [Idle-dev] Removing IDLE from the standard library In-Reply-To: References: Message-ID: 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 From taleinat at gmail.com Mon Jul 12 18:29:38 2010 From: taleinat at gmail.com (Tal Einat) Date: Mon, 12 Jul 2010 19:29:38 +0300 Subject: [Idle-dev] [Python-Dev] Removing IDLE from the standard library In-Reply-To: <878w5g3fc4.fsf@hydra.hampton.thirdcreek.com> References: <4C3A0F85.1090404@v.loewis.de> <11989_1278874767_o6BIxON2026376_EA883BC9-5C6B-4444-B0D7-1BA51815328F@twistedmatrix.com> <4C3A415F.6050709@v.loewis.de> <4C3A493E.8090308@v.loewis.de> <878w5g3fc4.fsf@hydra.hampton.thirdcreek.com> Message-ID: On Mon, Jul 12, 2010 at 6:11 PM, Kurt B. Kaiser wrote: > On Mon, Jul 12 2010, Tal Einat wrote: > >> On Mon, Jul 12, 2010 at 1:44 AM, "Martin v. L?wis" wrote: >>>> FWIW this is why I started IDLE-Spoon (well, continued Noam Raphael's >>>> project of the same name, in a sense). The idea was to have a fork of >>>> IDLE with new features which need to be tried out by "beta testers" to >>>> iron out all of the glitches before making it into the main version, >>>> like IDLE-fork back in the beginning of the decade. However I have >>>> utterly failed in promoting this project and getting "beta testers" on >>>> board, at least partially due to the lack of interest from the >>>> community (and admittedly my lack of PR skills). >>> >>> I think such a thing must inherently fail - precisely for these reasons. >>> >>> It's much better to release proposed new features along with Python, >>> and wait for feedback. Users won't start trying things out until after >>> the release. This is a general problem, and lead Barry Warsaw to believe >>> that "release candidates" are an utter waste of time. >> >> That's debatable, and I disagree. IDLE-fork was a great success, for example. > > We had major contributions from David Scherer, Guido, and Stephen Gava. > > But a key factor in its success was that I took it upon myself to keep > IDLEfork sync'd with core IDLE using a cvs vendor branch and frequent > merges. ?Once the project was completed, I arranged with SF to move the > IDLEfork repository, including history, back into Python. > > This was not done with Noam's branch. ?As a result, it gradually drifted > to the point where it became essentially unmergable. Actually, Noam's branch was pretty much merged back as is -- that's where IDLE's auto-completion functionality came from. The later changes he made on that branch were never merged, as you mentioned, because Noam never bothered. I have been maintaining my own fork of IDLE for several years and manually keeping it in sync with IDLE (this was simple). The difference is that there was no single major new feature I was working on, such as the addition of a sub-process in IDLE-fork or Noam's addition of auto-completion. I was mostly making relatively minor fixes and changes which were not interrelated. I saw no reason to have them all merged back at once, so I posted patches as soon as I felt they were ready, and did the best I could to get them accepted. I eventually gave up on this process because every patch took far too long to be addressed and finally accepted or rejected, and I realized that most of the work I had done would never be merged back into the mainstream version of IDLE. From glyph at twistedmatrix.com Mon Jul 12 21:48:12 2010 From: glyph at twistedmatrix.com (Glyph Lefkowitz) Date: Mon, 12 Jul 2010 15:48:12 -0400 Subject: [Idle-dev] [Python-Dev] Removing IDLE from the standard library In-Reply-To: References: <29559_1278893635_o6C0DslL000282_4C3A5983.3010002@holdenweb.com> <87sk3p2gzy.fsf@hydra.hampton.thirdcreek.com> Message-ID: <1D4152AC-DC35-4039-8970-22A0D5521C85@twistedmatrix.com> On Jul 12, 2010, at 11:36 AM, Reid Kleckner wrote: > (Somwhat off-topic): Another pain point students had was accidentally > shadowing stdlib modules, like random. Renaming the file didn't solve > the problem either, because it left behind .pycs, which I had to help > them delete. I feel your pain. It seems like every third person who starts playing with Twisted starts off by making a file called 'twisted.py' and then getting really confused by the behavior. I would love it if this could be fixed, but I haven't yet thought of a solution that would be less confusing than the problem itself. -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin at v.loewis.de Mon Jul 12 23:20:21 2010 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Mon, 12 Jul 2010 23:20:21 +0200 Subject: [Idle-dev] [Python-Dev] Removing IDLE from the standard library In-Reply-To: References: <217B30F6-06FE-4237-90C2-540CD6BB6A28@twistedmatrix.com> <4C3A48AE.9010707@v.loewis.de> Message-ID: <4C3B8715.9000605@v.loewis.de> Am 12.07.2010 13:01, schrieb Tal Einat: > On Mon, Jul 12, 2010 at 1:41 AM, "Martin v. L?wis" 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 From martin at v.loewis.de Mon Jul 12 23:49:15 2010 From: martin at v.loewis.de (=?windows-1252?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Mon, 12 Jul 2010 23:49:15 +0200 Subject: [Idle-dev] [Python-Dev] Removing IDLE from the standard library In-Reply-To: <4C3B533D.1080706@voidspace.org.uk> References: <4C3A0F85.1090404@v.loewis.de> <11989_1278874767_o6BIxON2026376_EA883BC9-5C6B-4444-B0D7-1BA51815328F@twistedmatrix.com> <4C3A415F.6050709@v.loewis.de> <4C3A4771.5090501@v.loewis.de> <20100712151927.456cbed3@pitrou.net> <4C3B2FB6.3050400@voidspace.org.uk> <4C3B533D.1080706@voidspace.org.uk> Message-ID: <4C3B8DDB.8070109@v.loewis.de> >> Not normally, no - there's no easy way to connect a checkin message to >> a committer's email address, > > There's a one-to-one mapping somewhere. Unfortunately, no: we don't have email addresses of all committers. Regards, Martin From benjamin at python.org Mon Jul 12 23:57:05 2010 From: benjamin at python.org (Benjamin Peterson) Date: Mon, 12 Jul 2010 16:57:05 -0500 Subject: [Idle-dev] [Python-Dev] Removing IDLE from the standard library In-Reply-To: <4C3B8DDB.8070109@v.loewis.de> References: <4C3A0F85.1090404@v.loewis.de> <11989_1278874767_o6BIxON2026376_EA883BC9-5C6B-4444-B0D7-1BA51815328F@twistedmatrix.com> <4C3A415F.6050709@v.loewis.de> <4C3A4771.5090501@v.loewis.de> <20100712151927.456cbed3@pitrou.net> <4C3B2FB6.3050400@voidspace.org.uk> <4C3B533D.1080706@voidspace.org.uk> <4C3B8DDB.8070109@v.loewis.de> Message-ID: 2010/7/12 "Martin v. L?wis" : >>> Not normally, no - there's no easy way to connect a checkin message to >>> a committer's email address, >> >> There's a one-to-one mapping somewhere. > > Unfortunately, no: we don't have email addresses of all committers. What about the python-committers mailing list? That has at least all the active ones, correct? -- Regards, Benjamin From martin at v.loewis.de Tue Jul 13 00:11:02 2010 From: martin at v.loewis.de (=?UTF-8?B?Ik1hcnRpbiB2LiBMw7Z3aXMi?=) Date: Tue, 13 Jul 2010 00:11:02 +0200 Subject: [Idle-dev] [Python-Dev] Removing IDLE from the standard library In-Reply-To: References: <4C3A0F85.1090404@v.loewis.de> <11989_1278874767_o6BIxON2026376_EA883BC9-5C6B-4444-B0D7-1BA51815328F@twistedmatrix.com> <4C3A415F.6050709@v.loewis.de> <4C3A4771.5090501@v.loewis.de> <20100712151927.456cbed3@pitrou.net> <4C3B2FB6.3050400@voidspace.org.uk> <4C3B533D.1080706@voidspace.org.uk> <4C3B8DDB.8070109@v.loewis.de> Message-ID: <4C3B92F6.4020807@v.loewis.de> Am 12.07.2010 23:57, schrieb Benjamin Peterson: > 2010/7/12 "Martin v. L?wis" : >>>> Not normally, no - there's no easy way to connect a checkin message to >>>> a committer's email address, >>> >>> There's a one-to-one mapping somewhere. >> >> Unfortunately, no: we don't have email addresses of all committers. > > What about the python-committers mailing list? That has at least all > the active ones, correct? Probably. Also, Dirkjan is maintaining a list for the Mercurial migration. So it is probably the case that one could be constructed if desired. It's just that "we" (the people maintaining the subversion access control) don't have such a list. Regards, Martin From memilanuk at gmail.com Tue Jul 13 06:34:04 2010 From: memilanuk at gmail.com (Monte Milanuk) Date: Mon, 12 Jul 2010 21:34:04 -0700 Subject: [Idle-dev] [Python-Dev] Removing IDLE from the standard library In-Reply-To: References: Message-ID: On 7/11/10 7:31 AM, Tal Einat wrote: > However, I still think IDLE is not currently in a state that it should > be suggested for use by beginners. Being one of those beginners... here's my $0.02 worth. IDLE being instantly available on pretty much anything I care to try my hand at python on... my Macbook, my desktop PC, Linux (inside Virtualbox), or even via PortablePython on my usb thumb drive... is priceless. Wherever I go, it just works. The defaults are fairly reasonable and comfortable on the platforms I've used it on. I don't have all the sidebars and bottom bars and gizmos and gadgets in my way - just a shell to try things in, and a basic editor to write code in. That said... some documentation (i.e. with examples) of using some of the other features (debugger, class & path browsers, etc.) would be nice. I think I posted a while back that some basic niceties for the editor like line numbers and 'show whitespace' would make things a little handier for the newbies out there. Just reading through this thread, it seems like the problem seems to be those who know how to fix the problems or make the enhancements... generally have 'moved on' more advanced editors or IDEs, and those who use IDLE regularly are often those who lack the knowledge of how to do bug reports, etc. and probably would be very discouraged to see it untouched for extended periods. Not sure there's an easy reconciliation between the two. The idea of a plain 'release' version and a possible enhanced 'development' version does have some interest for me personally... especially if 1) it stays easy to install/use, and 2) the enhancements get regularly rolled into the release versions. YMMV, Monte From cben at users.sf.net Tue Jul 13 10:11:07 2010 From: cben at users.sf.net (Beni Cherniavsky-Paskin) Date: Tue, 13 Jul 2010 11:11:07 +0300 Subject: [Idle-dev] Removing IDLE from the standard library In-Reply-To: References: <4C39DFD3.6040304@codebykevin.com> Message-ID: On Sun, Jul 11, 2010 at 18:20, Tal Einat wrote: > The (hopefully) compelling arguments were others, such as the sentence > following the one you quoted: > > "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." > > Having taught a few Python courses myself, I must say that while not perfect [I had to apologize for some IDLE issues, which shamed me into filing bugs/patches for some of them], it is *better* for interactive use than most other IDEs! That's IMHO the #1 is the real reason that makes it ideal for teaching, not the fact that it's bundled with Python. I wouldn't mind telling people "install Python and X" instead of "install Python", but very few Python environments do multiline history correctly :-(. The only one I know that beats IDLE is Dreampie (designed by Noam Raphael, a long time IDLE contributor). However, without an editor and F5 it's not a winner for teaching. For the record, I'm -42 on removing IDLE from the distribution (unless you have a better replacement?), but +1 on widening commit access and setting up one obvious way for users to try bleeding-edge IDLE. -0 on extracting it from the stdlib (it's one way to implement the above, not sure if best way). But here's a thought: why not make IDLE an early adopter of Mercurial? It seems to me that could ease a lot of the issues: - contributors will be able to publish their changes without waiting for official commiters - contributors will be able to maintain "beefed up" IDLE branches with much less pain - trying out bleeding-edge branches would be much simpler - I expect a de-facto "stable" IDLE branch will emerge from the community -- Beni Cherniavsky-Paskin -------------- next part -------------- An HTML attachment was scrubbed... URL: From g.brandl at gmx.net Wed Jul 14 10:10:02 2010 From: g.brandl at gmx.net (Georg Brandl) Date: Wed, 14 Jul 2010 10:10:02 +0200 Subject: [Idle-dev] Removing IDLE from the standard library In-Reply-To: References: <4C3A0F85.1090404@v.loewis.de> Message-ID: 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 From ggpolo at gmail.com Wed Jul 14 19:45:57 2010 From: ggpolo at gmail.com (Guilherme Polo) Date: Wed, 14 Jul 2010 14:45:57 -0300 Subject: [Idle-dev] [Python-Dev] Removing IDLE from the standard library In-Reply-To: References: <4C3C97E4.9000703@animats.com> Message-ID: 2010/7/14 Terry Reedy : > On 7/14/2010 2:35 AM, Giampaolo Rodol? wrote: >> >> One of the main problems with IDLE is the lack of tabs for editing >> multiple files within the same window. >> Having that alone would be a great improvement. > > Yes, the same as tabs for browsing was. > > This is firstly an unlying gui widget set issue. Tk does not, as far as I > know, have a tabbed document widget. Ttk has a new Notebook widget, with > tabs. > I have worked on this before, and I can tell you that simply changing to ttk widgets is the easiest part. My recommendation, that you are free to ignore (especially if you want to skip this previous work), is: as a first step change the EditWindow to act more like a EditPage. That is, you should be able to instantiate a EditWindow and include this new EditPage on it (as a child or something else that you may imagine). > -- > Terry Jan Reedy > -- -- Guilherme H. Polo Goncalves From solipsis at pitrou.net Sat Jul 17 13:33:25 2010 From: solipsis at pitrou.net (Antoine Pitrou) Date: Sat, 17 Jul 2010 13:33:25 +0200 Subject: [Idle-dev] IDLE contributors and committers References: Message-ID: <20100717133325.5f204ee9@pitrou.net> Hello, On Sun, 11 Jul 2010 02:05:22 +0300 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 haven't seen any conclusive statement or action to this thread. Without being an IDLE user myself (for good reason), I think that if IDLE should stay, active contributors such as Tal should be given commit access and enough free rein to maintain and improve it. Otherwise there's no reason to continue claiming that IDLE is important while discouraging such people's contributions. The current situation, where several core developers support IDLE's continued inclusion but none actually cares for the issues and patches in the tracker, is schizophrenic. Regards Antoine. From steve at holdenweb.com Sat Jul 17 13:47:38 2010 From: steve at holdenweb.com (Steve Holden) Date: Sat, 17 Jul 2010 07:47:38 -0400 Subject: [Idle-dev] IDLE contributors and committers In-Reply-To: <20100717133325.5f204ee9@pitrou.net> References: <20100717133325.5f204ee9@pitrou.net> Message-ID: <4C41985A.4030201@holdenweb.com> On 7/17/2010 7:33 AM, Antoine Pitrou wrote: > > Hello, > > On Sun, 11 Jul 2010 02:05:22 +0300 > 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 haven't seen any conclusive statement or action to this thread. > Without being an IDLE user myself (for good reason), I think that if > IDLE should stay, active contributors such as Tal should be given commit > access and enough free rein to maintain and improve it. > > Otherwise there's no reason to continue claiming that IDLE is important > while discouraging such people's contributions. The current situation, > where several core developers support IDLE's continued inclusion but > none actually cares for the issues and patches in the tracker, is > schizophrenic. > > Regards > > Antoine. +1 There's no reason why Tal should be obstructed in his goal of making IDLE at least acceptable again. It's fairly obvious thaat there aren't any committers who have both the inclination /and/ the time to do this, so adding Tal (and other interested parties) as a developer makes a lot of sense. 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/ From taleinat at gmail.com Sat Jul 17 16:57:34 2010 From: taleinat at gmail.com (Tal Einat) Date: Sat, 17 Jul 2010 17:57:34 +0300 Subject: [Idle-dev] IDLE contributors and committers In-Reply-To: <4C41985A.4030201@holdenweb.com> References: <20100717133325.5f204ee9@pitrou.net> <4C41985A.4030201@holdenweb.com> Message-ID: On Sat, Jul 17, 2010 at 2:47 PM, Steve Holden wrote: > On 7/17/2010 7:33 AM, Antoine Pitrou wrote: >> >> Hello, >> >> On Sun, 11 Jul 2010 02:05:22 +0300 >> 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 haven't seen any conclusive statement or action to this thread. >> Without being an IDLE user myself (for good reason), I think that if >> IDLE should stay, active contributors such as Tal should be given commit >> access and enough free rein to maintain and improve it. >> >> Otherwise there's no reason to continue claiming that IDLE is important >> while discouraging such people's contributions. The current situation, >> where several core developers support IDLE's continued inclusion but >> none actually cares for the issues and patches in the tracker, is >> schizophrenic. >> > +1 > > There's no reason why Tal should be obstructed in his goal of making > IDLE at least acceptable again. It's fairly obvious thaat there aren't > any committers who have both the inclination /and/ the time to do this, > so adding Tal (and other interested parties) as a developer makes a lot > of sense. I would certainly accept this as a first step. Although I now use IDLE much less than I have in previous years, I would be willing to put in some time towards fixing the major current issues and integrating the few polished enhancements. However, in the long run just allowing "heavy" contributors such as myself commit rights won't be enough. There's definitely a need for one or more active maintainers of IDLE who can take care of incoming bug reports and patches. We may hope that at least one serious contributor who is given commit rights will take up this position naturally, but perhaps a more active approach would be beneficial? I also think that there is a need for a guiding hand for IDLE, as Guido is for Python. It took a bit of time until I "got" the goals and principles of IDLE (e.g. easy to learn, minimal and obvious interface) by having KBK explain them in detail and explain the drawbacks of certain proposed changes. Having some kind of central authority is especially important in order to keep IDLE on track because the active development of IDLE is slow and done by various contributors -- there is currently no central group of active developers making such decisions. This doesn't have to be one person who also takes care of bugs, patches and testing, it could be someone who is just readily available via the idle-dev mailing list and keeps up with development of IDLE. Going along these lines of thought, I reach my original conclusion: IDLE is somewhat a project of its own. Perhaps considering IDLE a daughter-project of Python is appropriate, and continuing to develop it as part of the Python codebase could be reasonable, if more active maintainers can be found. I certainly support continuing to package it as part of the standard distribution. From solipsis at pitrou.net Sun Jul 18 17:59:09 2010 From: solipsis at pitrou.net (Antoine Pitrou) Date: Sun, 18 Jul 2010 17:59:09 +0200 Subject: [Idle-dev] IDLE contributors and committers References: <20100717133325.5f204ee9@pitrou.net> <4C41985A.4030201@holdenweb.com> Message-ID: <20100718175909.78e939bb@pitrou.net> On Sat, 17 Jul 2010 17:57:34 +0300 Tal Einat wrote: > > However, in the long run just allowing "heavy" contributors such as > myself commit rights won't be enough. There's definitely a need for > one or more active maintainers of IDLE who can take care of incoming > bug reports and patches. We may hope that at least one serious > contributor who is given commit rights will take up this position > naturally, but perhaps a more active approach would be beneficial? Well, the general problem can be solved stepwise. Here (since this discussion happens both on python-dev and idle-dev), I think we are firstly interested in how python-dev can allow IDLE development and maintenance to happen again. Hence my proposal for IDLE contributors to become committers. Then, idle-dev can do further proposals (for example, a dedicated IDLE development FAQ or manual, etc.). > I also think that there is a need for a guiding hand for IDLE, as > Guido is for Python. It took a bit of time until I "got" the goals and > principles of IDLE (e.g. easy to learn, minimal and obvious interface) > by having KBK explain them in detail and explain the drawbacks of > certain proposed changes. Having some kind of central authority is > especially important in order to keep IDLE on track because the active > development of IDLE is slow and done by various contributors -- there > is currently no central group of active developers making such > decisions. This doesn't have to be one person who also takes care of > bugs, patches and testing, it could be someone who is just readily > available via the idle-dev mailing list and keeps up with development > of IDLE. Or it could be several persons. "The IDLE maintainers", or "the IDLE committers". > Going along these lines of thought, I reach my original conclusion: > IDLE is somewhat a project of its own. Perhaps considering IDLE a > daughter-project of Python is appropriate, and continuing to develop > it as part of the Python codebase could be reasonable, if more active > maintainers can be found. I certainly support continuing to package it > as part of the standard distribution. The thing is, if we package it as part of the standard distribution: - IDLE development has to follow the release schedule (bugfix-only period, code freeze, etc.) - IDLE issues have to be considered Python issues, in that they affect the overall quality of Python (as perceived by users) Therefore, it would probably be counter-productive for IDLE to have a totally separate development environment (VCS, issue tracker) where the only communication with python-dev takes places before a new Python release. Regards Antoine. From glyph at twistedmatrix.com Sun Jul 18 21:57:57 2010 From: glyph at twistedmatrix.com (Glyph Lefkowitz) Date: Sun, 18 Jul 2010 15:57:57 -0400 Subject: [Idle-dev] [Python-Dev] What to do with languishing patches? In-Reply-To: References: Message-ID: <7B78A282-EADA-48BD-93DD-26719168E7B9@twistedmatrix.com> On Jul 18, 2010, at 1:46 PM, Alexander Belopolsky wrote: > We already have "posponed" and "remind" resolutions, but these are > exclusive of "accepted". I think there should be a clear way to mark > the issue "accepted and would be applied if X.Y was out already." > Chances are one of the resolution labels already has such meaning, but > in this case it should be more prominently documented as such. This is what branches are for. When the X.Y release cycle starts, there should be a branch for X.Y. Any "would be applied" patches can simply be applied to trunk without interrupting anything; the X.Y release branch can be merged back into trunk as necessary. -------------- next part -------------- An HTML attachment was scrubbed... URL: From martin at v.loewis.de Mon Jul 19 00:10:23 2010 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Sun, 18 Jul 2010 23:10:23 +0100 Subject: [Idle-dev] [Python-Dev] What to do with languishing patches? In-Reply-To: References: Message-ID: <4C437BCF.5000409@v.loewis.de> > Maybe going off on a tangent, but I find it frustrating because you > (plural) can't find a given module on the issue tracker. Say I'm looking > for issues relating to smtplib, all I can do is look in the title of the > issue. Have I missed something, or is there a need to have subsections > so that if Lib is selected, you can then find the appropriate module? If you think any specific feature is missing in the tracker, please post a report to the meta-tracker. Regards, Martin From nyamatongwe at gmail.com Mon Jul 12 13:14:08 2010 From: nyamatongwe at gmail.com (Neil Hodgson) Date: Mon, 12 Jul 2010 21:14:08 +1000 Subject: [Idle-dev] [Python-Dev] Removing IDLE from the standard library In-Reply-To: <87sk3p2gzy.fsf@hydra.hampton.thirdcreek.com> References: <29559_1278893635_o6C0DslL000282_4C3A5983.3010002@holdenweb.com> <87sk3p2gzy.fsf@hydra.hampton.thirdcreek.com> Message-ID: Kurt B. Kaiser: > I'm mystified about the comments that the GUI is ugly. ?It is minimal. > On XP, it looks exactly like an XP window with a simple menubar. ?Those > who haven't looked at it for awhile may not be aware of the recent > advances made by Tk in native look and feel. ?What is ugly? While Tk has improved at emulating native appearance, there are still many differences. On the main editing screen of IDLE, the most noticeable issue is that there is no horizontal scroll bar even though the text will move left when you move the caret beyond the rightmost visible character. The scrollbar and status bar have an appearance that looks to be from Windows 2000, not Windows XP and there is no resizing gripper on the right side of the status bar. The tear off menus are ugly as well as being non-standard on all three major platforms. Use the "Configure IDLE..." and an "idle" dialog appears that also looks to be from Windows 2000. I know Tk can do better than this as Git Gui (the Tk (8.5.8) program I use most often) at least shows XP themed buttons, scrollbars and other controls. However, the "idle" dialog (as well as Git Gui) shows the largest remaining problem for Tk user interfaces: keyboard navigation. When the "idle" dialog opens, try doing anything with the keyboard. Chances are nothing will happen. If you press Tab 16 times (yes, 16!) a focus rectangle will finally show on the "Bold" check box. Another Tab takes you to the "Indentation Width" slider. After that you don't see the focus until it wraps around to "Bold" again. The Enter key doesn't trigger OK and the Escape key doesn't let you escape. The Find and Replace dialogs are better as focus works as do Enter and Escape but none of the buttons have mnemonics. This may all sound like picking nits but details and consistency are important in user interfaces and this is just looking at the most easily discovered problems. Neil From rdmurray at bitdance.com Mon Jul 12 14:42:25 2010 From: rdmurray at bitdance.com (R. David Murray) Date: Mon, 12 Jul 2010 08:42:25 -0400 Subject: [Idle-dev] [Python-Dev] IRC culture (was: Removing IDLE from the standard library) In-Reply-To: References: <4C3A0F85.1090404@v.loewis.de> Message-ID: <20100712124225.5A2E3218BAA@kimball.webabinitio.net> On Sun, 11 Jul 2010 23:51:35 +0100, Mark Lawrence 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. From ncoghlan at gmail.com Mon Jul 12 16:42:17 2010 From: ncoghlan at gmail.com (Nick Coghlan) Date: Tue, 13 Jul 2010 00:42:17 +1000 Subject: [Idle-dev] [Python-Dev] Removing IDLE from the standard library In-Reply-To: <20100712151927.456cbed3@pitrou.net> References: <4C3A0F85.1090404@v.loewis.de> <11989_1278874767_o6BIxON2026376_EA883BC9-5C6B-4444-B0D7-1BA51815328F@twistedmatrix.com> <4C3A415F.6050709@v.loewis.de> <4C3A4771.5090501@v.loewis.de> <20100712151927.456cbed3@pitrou.net> Message-ID: On Mon, Jul 12, 2010 at 11:19 PM, Antoine Pitrou wrote: > +1. Don't be afraid. We are quite good at pointing out mistakes after > the fact :) Just make sure to subscribe to python-checkins and keep an eye out for replies to your commits. Most post hoc review comments come in as replies to the commit notifications :) Hmm, do we mention that part of the process in the dev docs anywhere?... and it turns out we do, as Brett included it in the Intro to Development article. Cheers, Nick. -- Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia From fuzzyman at voidspace.org.uk Mon Jul 12 17:07:34 2010 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Mon, 12 Jul 2010 16:07:34 +0100 Subject: [Idle-dev] [Python-Dev] Removing IDLE from the standard library In-Reply-To: References: <4C3A0F85.1090404@v.loewis.de> <11989_1278874767_o6BIxON2026376_EA883BC9-5C6B-4444-B0D7-1BA51815328F@twistedmatrix.com> <4C3A415F.6050709@v.loewis.de> <4C3A4771.5090501@v.loewis.de> <20100712151927.456cbed3@pitrou.net> Message-ID: <4C3B2FB6.3050400@voidspace.org.uk> On 12/07/2010 15:42, Nick Coghlan wrote: > On Mon, Jul 12, 2010 at 11:19 PM, Antoine Pitrou wrote: > >> +1. Don't be afraid. We are quite good at pointing out mistakes after >> the fact :) >> > Just make sure to subscribe to python-checkins and keep an eye out for > replies to your commits. Most post hoc review comments come in as > replies to the commit notifications :) > That mailing list (python-checkins) is way too high traffic for many committers to monitor. I hope people making comments on checkins also email the committer directly. All the best, Michael > Hmm, do we mention that part of the process in the dev docs > anywhere?... and it turns out we do, as Brett included it in the Intro > to Development article. > > Cheers, > Nick. > > -- 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. From reid.kleckner at gmail.com Mon Jul 12 17:36:16 2010 From: reid.kleckner at gmail.com (Reid Kleckner) Date: Mon, 12 Jul 2010 15:36:16 +0000 Subject: [Idle-dev] [Python-Dev] Removing IDLE from the standard library In-Reply-To: <87sk3p2gzy.fsf@hydra.hampton.thirdcreek.com> References: <29559_1278893635_o6C0DslL000282_4C3A5983.3010002@holdenweb.com> <87sk3p2gzy.fsf@hydra.hampton.thirdcreek.com> Message-ID: On Mon, Jul 12, 2010 at 9:20 AM, Kurt B. Kaiser wrote: > Also, the current right click edit action on Windows is to only open an > edit window; no shell. ?And it uses the subprocess! ?So, some of the > comments on this thread are not up to date. > > The reason that bug languished for two years was because first, it was a > bit of a hack, and second, Windows was problematic in that it reused > sockets and often left zombie subprocesses behind which couldn't be > killed except with the task manager. ?This causes real problems with > students - they lose confidence in the tool. > > Scherer and Weeble put together a patch using ephemeral ports which > nailed the problem, and I checked it in right away and > forward/backported it. That's great news! I TAed a freshman Python class this January, and Windows users ran into this problem a lot. Mostly when hitting 'x' in the upper right. Fortunately, some quick searching led me to the Python tracker where I found the workaround. :) (Somwhat off-topic): Another pain point students had was accidentally shadowing stdlib modules, like random. Renaming the file didn't solve the problem either, because it left behind .pycs, which I had to help them delete. Overall, I would say that IDLE worked very well in that situation, so while it does have its quirks, it worked very well for us. Imagine trying to get students started with Eclipse or NetBeans. Yuck! Reid From ncoghlan at gmail.com Mon Jul 12 17:52:02 2010 From: ncoghlan at gmail.com (Nick Coghlan) Date: Tue, 13 Jul 2010 01:52:02 +1000 Subject: [Idle-dev] [Python-Dev] Removing IDLE from the standard library In-Reply-To: <4C3B2FB6.3050400@voidspace.org.uk> References: <4C3A0F85.1090404@v.loewis.de> <11989_1278874767_o6BIxON2026376_EA883BC9-5C6B-4444-B0D7-1BA51815328F@twistedmatrix.com> <4C3A415F.6050709@v.loewis.de> <4C3A4771.5090501@v.loewis.de> <20100712151927.456cbed3@pitrou.net> <4C3B2FB6.3050400@voidspace.org.uk> Message-ID: On Tue, Jul 13, 2010 at 1:07 AM, Michael Foord wrote: > That mailing list (python-checkins) is way too high traffic for many > committers to monitor. I hope people making comments on checkins also email > the committer directly. Not normally, no - there's no easy way to connect a checkin message to a committer's email address, so it's usually just a matter of hitting "Reply" and sending the review comment to the list. With a new committer I'll make the effort to cc them directly in case they aren't subscribed yet, but I expect everyone else to be monitor the checkins list. If the list is too high volume, filter it down to just those issues with your checkin name in the "From" or "To" fields (your own checkin messages will have the former, while replies should have the latter, even though the email address in both cases will actually be python-checkins at python.org. Cheers, Nick. -- Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia From ncoghlan at gmail.com Mon Jul 12 18:14:26 2010 From: ncoghlan at gmail.com (Nick Coghlan) Date: Tue, 13 Jul 2010 02:14:26 +1000 Subject: [Idle-dev] [Python-Dev] Removing IDLE from the standard library In-Reply-To: <20100712174226.2c692abb@pitrou.net> References: <29559_1278893635_o6C0DslL000282_4C3A5983.3010002@holdenweb.com> <87sk3p2gzy.fsf@hydra.hampton.thirdcreek.com> <20100712121040.41f16654@pitrou.net> <87fwzo3nmt.fsf@hydra.hampton.thirdcreek.com> <20100712142200.6b57ef8d@pitrou.net> <874og43esn.fsf@hydra.hampton.thirdcreek.com> <20100712174226.2c692abb@pitrou.net> Message-ID: On Tue, Jul 13, 2010 at 1:44 AM, Bill Janssen wrote: > 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. FWIW, "./python -m idlelib,idle" launched the shell window for me on two development installs. "python -m idlelib.idle" didn't work intially on the system Python (since Kubuntu leaves idle out by default), but it worked fine once I installed the idle package. (Oh, and I can confirm it still looks like a Tcl/Tk app on Kubuntu rather than a KDE app even with Tk 8.5) Cheers, Nick. -- Nick Coghlan?? |?? ncoghlan at gmail.com?? |?? Brisbane, Australia From fuzzyman at voidspace.org.uk Mon Jul 12 19:39:09 2010 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Mon, 12 Jul 2010 18:39:09 +0100 Subject: [Idle-dev] [Python-Dev] Removing IDLE from the standard library In-Reply-To: References: <4C3A0F85.1090404@v.loewis.de> <11989_1278874767_o6BIxON2026376_EA883BC9-5C6B-4444-B0D7-1BA51815328F@twistedmatrix.com> <4C3A415F.6050709@v.loewis.de> <4C3A4771.5090501@v.loewis.de> <20100712151927.456cbed3@pitrou.net> <4C3B2FB6.3050400@voidspace.org.uk> Message-ID: <4C3B533D.1080706@voidspace.org.uk> On 12/07/2010 16:52, Nick Coghlan wrote: > On Tue, Jul 13, 2010 at 1:07 AM, Michael Foord > wrote: > > >> That mailing list (python-checkins) is way too high traffic for many >> committers to monitor. I hope people making comments on checkins also email >> the committer directly. >> > Not normally, no - there's no easy way to connect a checkin message to > a committer's email address, There's a one-to-one mapping somewhere. > so it's usually just a matter of hitting > "Reply" and sending the review comment to the list. With a new > committer I'll make the effort to cc them directly in case they aren't > subscribed yet, but I expect everyone else to be monitor the checkins > list. > Without contacting committers, rather than firing into the black depths of a high traffic list, I strongly suspect that much of the feedback is lost. All the best, Michael > If the list is too high volume, filter it down to just those issues > with your checkin name in the "From" or "To" fields (your own checkin > messages will have the former, while replies should have the latter, > even though the email address in both cases will actually be > python-checkins at python.org. > > Cheers, > Nick. > > -- 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. From ianb at colorstudy.com Mon Jul 12 20:21:54 2010 From: ianb at colorstudy.com (Ian Bicking) Date: Mon, 12 Jul 2010 11:21:54 -0700 Subject: [Idle-dev] [Python-Dev] Removing IDLE from the standard library In-Reply-To: References: Message-ID: On Sun, Jul 11, 2010 at 3:38 PM, Ron Adam 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuzzyman at voidspace.org.uk Mon Jul 12 20:36:03 2010 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Mon, 12 Jul 2010 19:36:03 +0100 Subject: [Idle-dev] [Python-Dev] Removing IDLE from the standard library In-Reply-To: References: Message-ID: <4C3B6093.70809@voidspace.org.uk> On 12/07/2010 19:21, Ian Bicking wrote: > On Sun, Jul 11, 2010 at 3:38 PM, Ron Adam > 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 at python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk > -- 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dirkjan at ochtman.nl Tue Jul 13 09:56:16 2010 From: dirkjan at ochtman.nl (Dirkjan Ochtman) Date: Tue, 13 Jul 2010 09:56:16 +0200 Subject: [Idle-dev] [Python-Dev] Removing IDLE from the standard library In-Reply-To: <4C3B92F6.4020807@v.loewis.de> References: <4C3A0F85.1090404@v.loewis.de> <11989_1278874767_o6BIxON2026376_EA883BC9-5C6B-4444-B0D7-1BA51815328F@twistedmatrix.com> <4C3A415F.6050709@v.loewis.de> <4C3A4771.5090501@v.loewis.de> <20100712151927.456cbed3@pitrou.net> <4C3B2FB6.3050400@voidspace.org.uk> <4C3B533D.1080706@voidspace.org.uk> <4C3B8DDB.8070109@v.loewis.de> <4C3B92F6.4020807@v.loewis.de> Message-ID: On Tue, Jul 13, 2010 at 00:11, "Martin v. L?wis" wrote: >>>> There's a one-to-one mapping somewhere. >>> >>> Unfortunately, no: we don't have email addresses of all committers. >> >> What about the python-committers mailing list? That has at least all >> the active ones, correct? > > Probably. Also, Dirkjan is maintaining a list for the Mercurial migration. Indeed: http://hg.python.org/pymigr/file/tip/author-map?style=raw I think I took email addresses from the public key list that Martin maintains for SVN etc and then augmented that with stuff from the mailing list archives and Google. The list is by no means guaranteed to be correct and fully up-to-date, but it's complete (save for maybe new committers from the last few weeks). Cheers, Dirkjan From brian.curtin at gmail.com Wed Jul 14 19:44:42 2010 From: brian.curtin at gmail.com (Brian Curtin) Date: Wed, 14 Jul 2010 12:44:42 -0500 Subject: [Idle-dev] [Python-Dev] Removing IDLE from the standard library In-Reply-To: References: <4C3A0F85.1090404@v.loewis.de> Message-ID: On Wed, Jul 14, 2010 at 11:34, 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. >> > > 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From g.rodola at gmail.com Wed Jul 14 22:24:30 2010 From: g.rodola at gmail.com (=?ISO-8859-1?Q?Giampaolo_Rodol=E0?=) Date: Wed, 14 Jul 2010 22:24:30 +0200 Subject: [Idle-dev] [Python-Dev] Removing IDLE from the standard library In-Reply-To: References: <4C3C97E4.9000703@animats.com> Message-ID: 2010/7/14 Guilherme Polo : > 2010/7/14 Terry Reedy : >> On 7/14/2010 2:35 AM, Giampaolo Rodol? wrote: >>> >>> One of the main problems with IDLE is the lack of tabs for editing >>> multiple files within the same window. >>> Having that alone would be a great improvement. >> >> Yes, the same as tabs for browsing was. >> >> This is firstly an unlying gui widget set issue. Tk does not, as far as I >> know, have a tabbed document widget. Ttk has a new Notebook widget, with >> tabs. >> > > I have worked on this before, and I can tell you that simply changing > to ttk widgets is the easiest part. My recommendation, that you are > free to ignore (especially if you want to skip this previous work), > is: as a first step change the EditWindow to act more like a EditPage. > That is, you should be able to instantiate a EditWindow and include > this new EditPage on it (as a child or something else that you may > imagine). > >> -- >> Terry Jan Reedy >> > > > > -- > -- Guilherme H. Polo Goncalves > _______________________________________________ > Python-Dev mailing list > Python-Dev at python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: http://mail.python.org/mailman/options/python-dev/g.rodola%40gmail.com > http://code.google.com/p/python-ttk/wiki/Screenshots Modified IDLE screenshots look impressive. Has Ttk (or something similar) ever been considered for inclusion? I think the problem here is more Tkinter itself rather than IDLE. Does spending energies on working on something (IDLE) based on such an old and features-limited module as Tkinter really worth the effort? Some major lacks like tabbed browsing can be fixed somehow but there always will be a big impediment deriving from using such an old graphic library which can't provide all the facilities offered by wx, gtk, etc... Maybe it would be better to first upgrade/improve Tkinter somehow; provide a gui toolkit that is *really* competitive, then start to seriously work on IDLE. My 2 cents --- Giampaolo http://code.google.com/p/pyftpdlib http://code.google.com/p/psutil From g.rodola at gmail.com Wed Jul 14 22:48:31 2010 From: g.rodola at gmail.com (=?ISO-8859-1?Q?Giampaolo_Rodol=E0?=) Date: Wed, 14 Jul 2010 22:48:31 +0200 Subject: [Idle-dev] [Python-Dev] Removing IDLE from the standard library In-Reply-To: References: <4C3C97E4.9000703@animats.com> Message-ID: http://docs.python.org/dev/whatsnew/2.7.html#ttk-themed-widgets-for-tk Sorry, I realized just now that ttk is already included in Python 2.7 and 3.2. 2010/7/14 Giampaolo Rodol? : > 2010/7/14 Guilherme Polo : >> 2010/7/14 Terry Reedy : >>> On 7/14/2010 2:35 AM, Giampaolo Rodol? wrote: >>>> >>>> One of the main problems with IDLE is the lack of tabs for editing >>>> multiple files within the same window. >>>> Having that alone would be a great improvement. >>> >>> Yes, the same as tabs for browsing was. >>> >>> This is firstly an unlying gui widget set issue. Tk does not, as far as I >>> know, have a tabbed document widget. Ttk has a new Notebook widget, with >>> tabs. >>> >> >> I have worked on this before, and I can tell you that simply changing >> to ttk widgets is the easiest part. My recommendation, that you are >> free to ignore (especially if you want to skip this previous work), >> is: as a first step change the EditWindow to act more like a EditPage. >> That is, you should be able to instantiate a EditWindow and include >> this new EditPage on it (as a child or something else that you may >> imagine). >> >>> -- >>> Terry Jan Reedy >>> >> >> >> >> -- >> -- Guilherme H. Polo Goncalves >> _______________________________________________ >> Python-Dev mailing list >> Python-Dev at python.org >> http://mail.python.org/mailman/listinfo/python-dev >> Unsubscribe: http://mail.python.org/mailman/options/python-dev/g.rodola%40gmail.com >> > > http://code.google.com/p/python-ttk/wiki/Screenshots > Modified IDLE screenshots look impressive. > Has Ttk (or something similar) ever been considered for inclusion? > I think the problem here is more Tkinter itself rather than IDLE. > Does spending energies on working on something (IDLE) based on such an > old and features-limited module as Tkinter really worth the effort? > > Some major lacks like tabbed browsing can be fixed somehow but there > always will be a big impediment deriving from using such an old > graphic library which can't provide all the facilities offered by wx, > gtk, etc... > > Maybe it would be better to first upgrade/improve Tkinter somehow; > provide a gui toolkit that is *really* competitive, then start to > seriously work on IDLE. > > > My 2 cents > > --- Giampaolo > http://code.google.com/p/pyftpdlib > http://code.google.com/p/psutil > From fuzzyman at voidspace.org.uk Sat Jul 17 13:50:50 2010 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Sat, 17 Jul 2010 12:50:50 +0100 Subject: [Idle-dev] [Python-Dev] IDLE contributors and committers In-Reply-To: <4C41985A.4030201@holdenweb.com> References: <20100717133325.5f204ee9@pitrou.net> <4C41985A.4030201@holdenweb.com> Message-ID: <4C41991A.9040103@voidspace.org.uk> On 17/07/2010 12:47, Steve Holden wrote: > On 7/17/2010 7:33 AM, Antoine Pitrou wrote: > >> Hello, >> >> On Sun, 11 Jul 2010 02:05:22 +0300 >> 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 haven't seen any conclusive statement or action to this thread. >> Without being an IDLE user myself (for good reason), I think that if >> IDLE should stay, active contributors such as Tal should be given commit >> access and enough free rein to maintain and improve it. >> >> Otherwise there's no reason to continue claiming that IDLE is important >> while discouraging such people's contributions. The current situation, >> where several core developers support IDLE's continued inclusion but >> none actually cares for the issues and patches in the tracker, is >> schizophrenic. >> >> Regards >> >> Antoine. >> > +1 > > There's no reason why Tal should be obstructed in his goal of making > IDLE at least acceptable again. It's fairly obvious thaat there aren't > any committers who have both the inclination /and/ the time to do this, > so adding Tal (and other interested parties) as a developer makes a lot > of sense. > Guilherme's *existing* patch for IDLE looks like it improves it a great deal, at the cost of potentially requiring Tk 8.5 (?). Can this just be committed? https://code.google.com/p/python-ttk/wiki/Screenshots Michael Foord > regards > Steve > -- 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. From alexander.belopolsky at gmail.com Sun Jul 18 19:46:45 2010 From: alexander.belopolsky at gmail.com (Alexander Belopolsky) Date: Sun, 18 Jul 2010 13:46:45 -0400 Subject: [Idle-dev] What to do with languishing patches? Message-ID: On Sat, Jul 17, 2010 at 7:45 PM, Mark Lawrence wrote: > On 17/07/2010 22:57, Terry Reedy wrote: .. >> I am certainly reluctant to recruit others to help, as I did for #9222, >> if there will be no action indefinitely. >> > > This is standard Python behavour. ?The worst case I've come across is a > patch that dated back to 2001 that had not been dealt with. ?But I'm > staggered as to how a third party supplies a patch for (say) 2.3, it doesn't > get applied, then the issue tracker simply keeps updating the version > targeted until we're now at 3.2. ?That of course doesn't mean that anything > will get done, better wait until py4.7? > If this is the reputation that Python gets as a project, I think it is alarming. I was going to dismiss Mark's comment as over dramatizing the situation, but unfortunately it is not. Let me focus on a specific example not because it is important, but because it illustrates many different problems in an easy to understand case. The issue is http://bugs.python.org/issue1699259, which is a very simple patch submitted back in 2007. I came across that patch a year an a half later and posted a review. OP responded the next day and posted an updated patch. I gave the resulting patch a positive review, but the timing was unfortunate because it was during RC phase for 3.0. At the time, I made a prediction that 'deferring [the patch] to 2.7 and 3.1 [was] virtually equivalent to closing with "won't fix"'. That was quite right: the next comment came a year later with "Moving the 3.1 target to 3.2, since 3.1 is out" only to be forgotten for another year to be rediscovered in Mark's recent crusade. As I said, the issue is not an important one, but I noticed that OP did not submit any other patch or commented on any other issue since then. It is impossible to tell if he was turned off by the lack of attention to his patch, but I think it is likely that Python is loosing contributors when they submit a patch, respond to reviews and see their patch languish for no specified reason. I think there is at least one improvement that we can make. We can set up a mechanism that will assure that acceptable patches that don't get applied because they come at the wrong time in development cycle, get applied early in the development of the next release. We already have "posponed" and "remind" resolutions, but these are exclusive of "accepted". I think there should be a clear way to mark the issue "accepted and would be applied if X.Y was out already." Chances are one of the resolution labels already has such meaning, but in this case it should be more prominently documented as such. From p.f.moore at gmail.com Sun Jul 18 22:32:34 2010 From: p.f.moore at gmail.com (Paul Moore) Date: Sun, 18 Jul 2010 21:32:34 +0100 Subject: [Idle-dev] [Python-Dev] What to do with languishing patches? In-Reply-To: <7B78A282-EADA-48BD-93DD-26719168E7B9@twistedmatrix.com> References: <7B78A282-EADA-48BD-93DD-26719168E7B9@twistedmatrix.com> Message-ID: On 18 July 2010 20:57, Glyph Lefkowitz wrote: > > On Jul 18, 2010, at 1:46 PM, Alexander Belopolsky wrote: > > We already have "posponed" and "remind" resolutions, but these are > exclusive of "accepted". ??I think there should be a clear way to mark > the issue "accepted and would be applied if X.Y was out already." > Chances are one of the resolution labels already has such meaning, but > in this case it should be more prominently documented as such. > > This is what branches are for. > When the X.Y release cycle starts, there should be a branch for X.Y. ?Any > "would be applied" patches can simply be applied to trunk without > interrupting anything; the X.Y release branch can be merged back into trunk > as necessary. Agreed. If that isn't already the recommended workflow under Mercurial, I'd suggest making it so. (I can imagine that under Subversion, where branching and merging is more awkward, it might have been deemed not worth doing). Paul. From alexander.belopolsky at gmail.com Sun Jul 18 23:05:20 2010 From: alexander.belopolsky at gmail.com (Alexander Belopolsky) Date: Sun, 18 Jul 2010 17:05:20 -0400 Subject: [Idle-dev] [Python-Dev] What to do with languishing patches? In-Reply-To: References: <7B78A282-EADA-48BD-93DD-26719168E7B9@twistedmatrix.com> Message-ID: On Sun, Jul 18, 2010 at 4:32 PM, Paul Moore wrote: > On 18 July 2010 20:57, Glyph Lefkowitz wrote: .. >> This is what branches are for. >> When the X.Y release cycle starts, there should be a branch for X.Y. ?Any >> "would be applied" patches can simply be applied to trunk without >> interrupting anything; the X.Y release branch can be merged back into trunk >> as necessary. > > Agreed. If that isn't already the recommended workflow under > Mercurial, I'd suggest making it so. (I can imagine that under > Subversion, where branching and merging is more awkward, it might have > been deemed not worth doing). Do I understand it correctly that the proposal is to create an X.Y-maint branch at the time when alpha (or beta) release goes out rather than the current practice of creating the branch at the time of the final release? In this case issue1699259 patch could be committed to py3k branch without affecting what goes into 3.0. I still don't understand why "Python 2.6 is already out" was a reason not to commit it to trunk at the time. From alexander.belopolsky at gmail.com Mon Jul 19 00:38:09 2010 From: alexander.belopolsky at gmail.com (Alexander Belopolsky) Date: Sun, 18 Jul 2010 18:38:09 -0400 Subject: [Idle-dev] [Python-Dev] What to do with languishing patches? In-Reply-To: <4C437BCF.5000409@v.loewis.de> References: <4C437BCF.5000409@v.loewis.de> Message-ID: On Sun, Jul 18, 2010 at 6:10 PM, "Martin v. L?wis" wrote: >> Maybe going off on a tangent, but I find it frustrating because you >> (plural) can't find a given module on the issue tracker. Say I'm looking >> for issues relating to smtplib, all I can do is look in the title of the >> issue. Have I missed something, or is there a need to have subsections >> so that if Lib is selected, you can then find the appropriate module? > > If you think any specific feature is missing in the tracker, please post > a report to the meta-tracker. This is an excellent point and for those who don't know what "meta-tracker" is, see the link to "Report Tracker Problem" at the bottom of left column on the main tracker page. The direct link is http://psf.upfronthosting.co.za/roundup/meta/ . (I did not know about the "meta-tracker" myself until a couple of months ago.) From steve at holdenweb.com Sat Jul 17 13:47:38 2010 From: steve at holdenweb.com (Steve Holden) Date: Sat, 17 Jul 2010 07:47:38 -0400 Subject: [Idle-dev] IDLE contributors and committers In-Reply-To: <20100717133325.5f204ee9@pitrou.net> References: <20100717133325.5f204ee9@pitrou.net> Message-ID: <4C41985A.4030201@holdenweb.com> On 7/17/2010 7:33 AM, Antoine Pitrou wrote: > > Hello, > > On Sun, 11 Jul 2010 02:05:22 +0300 > 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 haven't seen any conclusive statement or action to this thread. > Without being an IDLE user myself (for good reason), I think that if > IDLE should stay, active contributors such as Tal should be given commit > access and enough free rein to maintain and improve it. > > Otherwise there's no reason to continue claiming that IDLE is important > while discouraging such people's contributions. The current situation, > where several core developers support IDLE's continued inclusion but > none actually cares for the issues and patches in the tracker, is > schizophrenic. > > Regards > > Antoine. +1 There's no reason why Tal should be obstructed in his goal of making IDLE at least acceptable again. It's fairly obvious thaat there aren't any committers who have both the inclination /and/ the time to do this, so adding Tal (and other interested parties) as a developer makes a lot of sense. 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/ From alexander.belopolsky at gmail.com Tue Jul 20 06:19:36 2010 From: alexander.belopolsky at gmail.com (Alexander Belopolsky) Date: Tue, 20 Jul 2010 00:19:36 -0400 Subject: [Idle-dev] [Python-Dev] What to do with languishing patches? In-Reply-To: References: <4C437BCF.5000409@v.loewis.de> Message-ID: On Mon, Jul 19, 2010 at 11:55 PM, Mark Lawrence wrote: .. > Is this the same login as for the issue tracker or is a new one needed? > AFAIK, it is separate. > I also suspect that subsections for Extension Modules would be extremely > useful for our C developers, thoughts anybody? Well, with the current trend of making extensions an optional fast reimplementation of library modules, the distinction between Lib and Extension Modules gets blurred. For example, http://bugs.python.org/issue1062277, "Pickle breakage with reduction of recursive structures" is a bug that affects both python and C implementation of pickle module. Should this be Lib or Extension issue or both? (The issue is actually misclassified as "Interpreter Core".) I think it is both. Here is a less clear example. Suppose someone reports a bug is time.strptime. The time module is a C extension, but strptime is implemented in a "hidden" python module, _strptime. How would you classify this issue? If your head does not spin yet, consider http://bugs.python.org/issue1677872, "Efficient reverse line iterator". When the patch was submitted, io module was implemented in python, but since then it was reimplemented in C. If we allow tagging issues with the module name, I would rather not make distinction between C and python modules. just make it one flat list similar to the one in maintainers.txt. From fijall at gmail.com Tue Jul 20 07:35:31 2010 From: fijall at gmail.com (Maciej Fijalkowski) Date: Tue, 20 Jul 2010 07:35:31 +0200 Subject: [Idle-dev] [Python-Dev] What to do with languishing patches? In-Reply-To: References: <7B78A282-EADA-48BD-93DD-26719168E7B9@twistedmatrix.com> Message-ID: On Sun, Jul 18, 2010 at 10:32 PM, Paul Moore wrote: > On 18 July 2010 20:57, Glyph Lefkowitz wrote: >> >> On Jul 18, 2010, at 1:46 PM, Alexander Belopolsky wrote: >> >> We already have "posponed" and "remind" resolutions, but these are >> exclusive of "accepted". ??I think there should be a clear way to mark >> the issue "accepted and would be applied if X.Y was out already." >> Chances are one of the resolution labels already has such meaning, but >> in this case it should be more prominently documented as such. >> >> This is what branches are for. >> When the X.Y release cycle starts, there should be a branch for X.Y. ?Any >> "would be applied" patches can simply be applied to trunk without >> interrupting anything; the X.Y release branch can be merged back into trunk >> as necessary. > > Agreed. If that isn't already the recommended workflow under > Mercurial, I'd suggest making it so. (I can imagine that under > Subversion, where branching and merging is more awkward, it might have > been deemed not worth doing). > > Paul. Contrary to a widespread popular belief subversion supports branching and I don't think anyone suggested merging release branches back (even though you can do it in subversion as well). Cheers, fijal From stephen at xemacs.org Tue Jul 20 07:37:17 2010 From: stephen at xemacs.org (Stephen J. Turnbull) Date: Tue, 20 Jul 2010 14:37:17 +0900 Subject: [Idle-dev] [Python-Dev] What to do with languishing patches? In-Reply-To: References: <4C437BCF.5000409@v.loewis.de> Message-ID: <877hkqzpbm.fsf@uwakimon.sk.tsukuba.ac.jp> Mark Lawrence writes: > Is this the same login as for the issue tracker or is a new one needed? It's different. Both trackers are supposed to support OpenID logins, I believe. (However, there are somewhat frequent reports of difficulties with it; I don't know if the system is fully debugged. I think most people are OK, but making a new login is the sure path.) > I also suspect that subsections for Extension Modules would be extremely > useful for our C developers, thoughts anybody? Do you mean an entry per module? The XEmacs Tracker (http://tracker.xemacs.org/), which also is based on Roundup, has an extensive list of add-on packages (somewhat like the stdlib). We're currently stuck in the doldrums, and it is sadly mostly unused, so I can't really comment on the utility. I find that there are some UI issues with such long lists in Roundup. I don't want to discourage adding such information to the tracker; I think it's a good idea. But it will need attention to UI to be most useful. From fijall at gmail.com Tue Jul 20 07:35:31 2010 From: fijall at gmail.com (Maciej Fijalkowski) Date: Tue, 20 Jul 2010 07:35:31 +0200 Subject: [Idle-dev] [Python-Dev] What to do with languishing patches? In-Reply-To: References: <7B78A282-EADA-48BD-93DD-26719168E7B9@twistedmatrix.com> Message-ID: On Sun, Jul 18, 2010 at 10:32 PM, Paul Moore wrote: > On 18 July 2010 20:57, Glyph Lefkowitz wrote: >> >> On Jul 18, 2010, at 1:46 PM, Alexander Belopolsky wrote: >> >> We already have "posponed" and "remind" resolutions, but these are >> exclusive of "accepted". ??I think there should be a clear way to mark >> the issue "accepted and would be applied if X.Y was out already." >> Chances are one of the resolution labels already has such meaning, but >> in this case it should be more prominently documented as such. >> >> This is what branches are for. >> When the X.Y release cycle starts, there should be a branch for X.Y. ?Any >> "would be applied" patches can simply be applied to trunk without >> interrupting anything; the X.Y release branch can be merged back into trunk >> as necessary. > > Agreed. If that isn't already the recommended workflow under > Mercurial, I'd suggest making it so. (I can imagine that under > Subversion, where branching and merging is more awkward, it might have > been deemed not worth doing). > > Paul. Contrary to a widespread popular belief subversion supports branching and I don't think anyone suggested merging release branches back (even though you can do it in subversion as well). Cheers, fijal _______________________________________________ Python-Dev mailing list Python-Dev at python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/mark%40ironport.com From taleinat at gmail.com Wed Jul 21 12:08:03 2010 From: taleinat at gmail.com (Tal Einat) Date: Wed, 21 Jul 2010 13:08:03 +0300 Subject: [Idle-dev] Rework when IDLE opens editor and/or shell windows Message-ID: I'd like to hear some comments on my thinking regarding this. I started thinking about this thanks to http://bugs.python.org/issue6698. Here is my last comment on that issue: After looking through the code and experimenting a bit, I propose the following: The "editor-on-startup" config option should be removed. Running IDLE without arguments should open a shell. If IDLE is asked to open any files for editing, it should open just editor windows. IDLE should open both a shell window and one or more editor windows only when explicitly asked to do so on the command line. If this is done, the -e option ("open an editor") would tell IDLE to open an empty editor window if no files are asked to be opened for editing. If no other arguments are given, IDLE will open just an editor window (no shell window). The -i option ("open a shell") would tell IDLE to open a shell window even if asked to open files for editing. I think this is more obvious and easier to work with. It will also make the command line argument processing code simpler. And as a bonus we remove a config option :) Thoughts? Comments? If there is agreement I will work up a patch. From basherwo at ncsu.edu Wed Jul 21 16:54:56 2010 From: basherwo at ncsu.edu (Bruce Sherwood) Date: Wed, 21 Jul 2010 08:54:56 -0600 Subject: [Idle-dev] Rework when IDLE opens editor and/or shell windows In-Reply-To: <15706_1279707242_o6LAE0o6016509_AANLkTimtvO6zKJRBOUd3EOsnxtlHd4mn-zRz9abyuX-k@mail.gmail.com> References: <15706_1279707242_o6LAE0o6016509_AANLkTimtvO6zKJRBOUd3EOsnxtlHd4mn-zRz9abyuX-k@mail.gmail.com> Message-ID: If you're speaking solely about running IDLE from a command line I don't care what the situation is. But it is extremely important to me that my students (and I) be able to start IDLE in such a way that what one sees is a blank edit window and no shell window, on all platforms (Windows, Mac, Linux). If there is some way to continue to be able to do this, by means of how the script/shortcut is set up, fine. But you seem to be proposing that this behavior would in the future be eliminated, which is not acceptable. Bruce Sherwood On Wed, Jul 21, 2010 at 4:08 AM, Tal Einat wrote: > I'd like to hear some comments on my thinking regarding this. > > I started thinking about this thanks to > http://bugs.python.org/issue6698. Here is my last comment on that > issue: > > After looking through the code and experimenting a bit, I propose the following: > > The "editor-on-startup" config option should be removed. Running IDLE > without arguments should open a shell. If IDLE is asked to open any > files for editing, it should open just editor windows. IDLE should > open both a shell window and one or more editor windows only when > explicitly asked to do so on the command line. > > If this is done, the -e option ("open an editor") would tell IDLE to > open an empty editor window if no files are asked to be opened for > editing. If no other arguments are given, IDLE will open just an > editor window (no shell window). The -i option ("open a shell") would > tell IDLE to open a shell window even if asked to open files for > editing. > > I think this is more obvious and easier to work with. It will also > make the command line argument processing code simpler. And as a bonus > we remove a config option :) > > Thoughts? Comments? If there is agreement I will work up a patch. > _______________________________________________ > IDLE-dev mailing list > IDLE-dev at python.org > http://mail.python.org/mailman/listinfo/idle-dev > From kw at codebykevin.com Wed Jul 21 16:58:01 2010 From: kw at codebykevin.com (Kevin Walzer) Date: Wed, 21 Jul 2010 10:58:01 -0400 Subject: [Idle-dev] Rework when IDLE opens editor and/or shell windows In-Reply-To: References: Message-ID: <4C470AF9.9080709@codebykevin.com> On 7/21/10 6:08 AM, Tal Einat wrote: > > The "editor-on-startup" config option should be removed. Running IDLE > without arguments should open a shell. If IDLE is asked to open any > files for editing, it should open just editor windows. IDLE should > open both a shell window and one or more editor windows only when > explicitly asked to do so on the command line. > > If this is done, the -e option ("open an editor") would tell IDLE to > open an empty editor window if no files are asked to be opened for > editing. If no other arguments are given, IDLE will open just an > editor window (no shell window). The -i option ("open a shell") would > tell IDLE to open a shell window even if asked to open files for > editing. > > I think this is more obvious and easier to work with. It will also > make the command line argument processing code simpler. And as a bonus > we remove a config option :) I'm not sure if I agree with this or not, but it appears to me that this proposal is mostly relevant for X11-based systems. On the Mac I open IDLE by double-clicking its app icon, not from the terminal; it appears that IDLE opens a shell by default in this context and opens both the shell and any files that are dropped on the app icon. I'm also not sure how IDLE works on Windows in this regard. Comments? -- Kevin Walzer Code by Kevin http://www.codebykevin.com From ggpolo at gmail.com Wed Jul 21 17:04:31 2010 From: ggpolo at gmail.com (Guilherme Polo) Date: Wed, 21 Jul 2010 12:04:31 -0300 Subject: [Idle-dev] Rework when IDLE opens editor and/or shell windows In-Reply-To: <4C470AF9.9080709@codebykevin.com> References: <4C470AF9.9080709@codebykevin.com> Message-ID: 2010/7/21 Kevin Walzer : > On 7/21/10 6:08 AM, Tal Einat wrote: >> >> The "editor-on-startup" config option should be removed. Running IDLE >> without arguments should open a shell. If IDLE is asked to open any >> files for editing, it should open just editor windows. IDLE should >> open both a shell window and one or more editor windows only when >> explicitly asked to do so on the command line. >> >> If this is done, the -e option ("open an editor") would tell IDLE to >> open an empty editor window if no files are asked to be opened for >> editing. If no other arguments are given, IDLE will open just an >> editor window (no shell window). The -i option ("open a shell") would >> tell IDLE to open a shell window even if asked to open files for >> editing. >> >> I think this is more obvious and easier to work with. It will also >> make the command line argument processing code simpler. And as a bonus >> we remove a config option :) > > I'm not sure if I agree with this or not, but it appears to me that this > proposal is mostly relevant for X11-based systems. On the Mac I open IDLE by > double-clicking its app icon, not from the terminal; it appears that IDLE > opens a shell by default in this context and opens both the shell and any > files that are dropped on the app icon. I'm also not sure how IDLE works on > Windows in this regard. Comments? > It is important to read the first message on the issue mentioned earlier. -- -- Guilherme H. Polo Goncalves From clockworksaint at gmail.com Wed Jul 21 19:59:42 2010 From: clockworksaint at gmail.com (Weeble) Date: Wed, 21 Jul 2010 18:59:42 +0100 Subject: [Idle-dev] Rework when IDLE opens editor and/or shell windows In-Reply-To: References: Message-ID: On Wed, Jul 21, 2010 at 11:08 AM, Tal Einat wrote: > Thoughts? Comments? If there is agreement I will work up a patch. Personally, I would slightly prefer that the default behaviour on starting IDLE via the shortcut in the start menu is to open a blank document and no shell window. I think of IDLE first and foremost as an editor, and I prefer it to behave like other editors that start up with a blank document. But this may be better dealt with by tweaking the shortcuts/launchers created by the installer. PS - I see my name mentioned in the log of revision 71126. I'm pretty sure the changes to enable_shell were not part of my original patch. Perhaps Kurt included them entirely by accident? I'm not sure whether they're related to the sub-process problem. From basherwo at ncsu.edu Wed Jul 21 20:54:55 2010 From: basherwo at ncsu.edu (Bruce Sherwood) Date: Wed, 21 Jul 2010 12:54:55 -0600 Subject: [Idle-dev] Rework when IDLE opens editor and/or shell windows In-Reply-To: <22770_1279735209_o6LI082J024324_AANLkTi=hV1fB6-oX4M0FDFzYcnVL0W5HiQs4kkUvZ1WC@mail.gmail.com> References: <22770_1279735209_o6LI082J024324_AANLkTi=hV1fB6-oX4M0FDFzYcnVL0W5HiQs4kkUvZ1WC@mail.gmail.com> Message-ID: I agree completely with Weeble but can continue to live with starting as an editor being a configuration parameter (VIDLE in fact ships with this set to "start in editor"). Note that if you're starting from a command line, you already have a (primitive) shell available: just start Python instead of IDLE. Bruce Sherwood On Wed, Jul 21, 2010 at 11:59 AM, Weeble wrote: > On Wed, Jul 21, 2010 at 11:08 AM, Tal Einat wrote: >> Thoughts? Comments? If there is agreement I will work up a patch. > > Personally, I would slightly prefer that the default behaviour on > starting IDLE via the shortcut in the start menu is to open a blank > document and no shell window. I think of IDLE first and foremost as an > editor, and I prefer it to behave like other editors that start up > with a blank document. But this may be better dealt with by tweaking > the shortcuts/launchers created by the installer. From taleinat at gmail.com Wed Jul 21 21:22:24 2010 From: taleinat at gmail.com (Tal Einat) Date: Wed, 21 Jul 2010 22:22:24 +0300 Subject: [Idle-dev] Rework when IDLE opens editor and/or shell windows In-Reply-To: References: <22770_1279735209_o6LI082J024324_AANLkTi=hV1fB6-oX4M0FDFzYcnVL0W5HiQs4kkUvZ1WC@mail.gmail.com> Message-ID: On Wed, Jul 21, 2010 at 9:54 PM, Bruce Sherwood wrote: > On Wed, Jul 21, 2010 at 11:59 AM, Weeble wrote: >> On Wed, Jul 21, 2010 at 11:08 AM, Tal Einat wrote: >>> Thoughts? Comments? If there is agreement I will work up a patch. >> >> Personally, I would slightly prefer that the default behaviour on >> starting IDLE via the shortcut in the start menu is to open a blank >> document and no shell window. I think of IDLE first and foremost as an >> editor, and I prefer it to behave like other editors that start up >> with a blank document. But this may be better dealt with by tweaking >> the shortcuts/launchers created by the installer. > > I agree completely with Weeble but can continue to live with starting > as an editor being a configuration parameter (VIDLE in fact ships with > this set to "start in editor"). > > Note that if you're starting from a command line, you already have a > (primitive) shell available: just start Python instead of IDLE. > > Bruce Sherwood Ok, it seems several people want to keep the config option to have IDLE open with an empty editor window instead of a shell window by default. How about we make it so that this config option only affects what IDLE does when run without any other arguments, such as via IDLE.app? In any other case, I think IDLE should ignore the "start-with-editor" config option. From clockworksaint at gmail.com Wed Jul 21 21:59:59 2010 From: clockworksaint at gmail.com (Weeble) Date: Wed, 21 Jul 2010 20:59:59 +0100 Subject: [Idle-dev] Rework when IDLE opens editor and/or shell windows In-Reply-To: References: <22770_1279735209_o6LI082J024324_AANLkTi=hV1fB6-oX4M0FDFzYcnVL0W5HiQs4kkUvZ1WC@mail.gmail.com> Message-ID: On Wed, Jul 21, 2010 at 8:22 PM, Tal Einat wrote: > Ok, it seems several people want to keep the config option to have > IDLE open with an empty editor window instead of a shell window by > default. How about we make it so that this config option only affects > what IDLE does when run without any other arguments, such as via > IDLE.app? In any other case, I think IDLE should ignore the > "start-with-editor" config option. I think that makes sense. The command-line should always be able to override the config option. From basherwo at ncsu.edu Wed Jul 21 22:09:37 2010 From: basherwo at ncsu.edu (Bruce Sherwood) Date: Wed, 21 Jul 2010 14:09:37 -0600 Subject: [Idle-dev] Rework when IDLE opens editor and/or shell windows In-Reply-To: References: <22770_1279735209_o6LI082J024324_AANLkTi=hV1fB6-oX4M0FDFzYcnVL0W5HiQs4kkUvZ1WC@mail.gmail.com> Message-ID: Agreed. As I indicated earlier, I don't care what happens from a command line, since unskilled users of Python and IDLE are very unlikely to start from a command line, and power users should have full flexibility. Bruce Sherwood On Wed, Jul 21, 2010 at 1:59 PM, Weeble wrote: > On Wed, Jul 21, 2010 at 8:22 PM, Tal Einat wrote: >> Ok, it seems several people want to keep the config option to have >> IDLE open with an empty editor window instead of a shell window by >> default. How about we make it so that this config option only affects >> what IDLE does when run without any other arguments, such as via >> IDLE.app? In any other case, I think IDLE should ignore the >> "start-with-editor" config option. > > I think that makes sense. The command-line should always be able to > override the config option. > From breamoreboy at yahoo.co.uk Tue Jul 20 05:55:29 2010 From: breamoreboy at yahoo.co.uk (Mark Lawrence) Date: Tue, 20 Jul 2010 04:55:29 +0100 Subject: [Idle-dev] [Python-Dev] What to do with languishing patches? In-Reply-To: References: <4C437BCF.5000409@v.loewis.de> Message-ID: On 18/07/2010 23:38, Alexander Belopolsky wrote: > On Sun, Jul 18, 2010 at 6:10 PM, "Martin v. L?wis" wrote: >>> Maybe going off on a tangent, but I find it frustrating because you >>> (plural) can't find a given module on the issue tracker. Say I'm looking >>> for issues relating to smtplib, all I can do is look in the title of the >>> issue. Have I missed something, or is there a need to have subsections >>> so that if Lib is selected, you can then find the appropriate module? >> >> If you think any specific feature is missing in the tracker, please post >> a report to the meta-tracker. > > This is an excellent point and for those who don't know what > "meta-tracker" is, see the link to "Report Tracker Problem" at the > bottom of left column on the main tracker page. The direct link is > http://psf.upfronthosting.co.za/roundup/meta/ . (I did not know about > the "meta-tracker" myself until a couple of months ago.) Is this the same login as for the issue tracker or is a new one needed? I also suspect that subsections for Extension Modules would be extremely useful for our C developers, thoughts anybody? Cheers. Mark Lawrence. _______________________________________________ Python-Dev mailing list Python-Dev at python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/mark%40ironport.com From tjreedy at udel.edu Sun Jul 25 04:30:57 2010 From: tjreedy at udel.edu (Terry Reedy) Date: Sat, 24 Jul 2010 22:30:57 -0400 Subject: [Idle-dev] Rework when IDLE opens editor and/or shell windows In-Reply-To: <4C470AF9.9080709@codebykevin.com> References: <4C470AF9.9080709@codebykevin.com> Message-ID: On 7/21/2010 10:58 AM, Kevin Walzer wrote: > I'm also not sure how IDLE works on Windows in this regard. Comments? WinXP, Py3.1, Start Menu/Programs/Python3.1/ shortcuts The IDLE and Interpreter shortcuts are not 'normal'. On the Shortcut tab of the Properties dialog, the Target location: field is blank and the Target: field is a grayed-out, uneditable and useless 'Python 3.1.2'. And this is as admin user. By comparison, a Windows Media Player shortcut says T location: Windows Media Player (read-only, should be called Target name:). Target: has "C:path/to/WMP/wmplayer.exe" /prefetch 1 in an editable box. So whatever /prefetch 1 means, I could change it. The Python shortcuts seems possibly buggy to me, but the point is that command line args are currently useless without informing users how to create a proper, editable shortcut where one could use them. I do not care at the moment because I always want a shell window and can easily open a edit window. The only reason not to open a shell that I can see is if one is editing non-Python files. -- Terry Jan Reedy From martin at v.loewis.de Sun Jul 25 23:08:42 2010 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Sun, 25 Jul 2010 23:08:42 +0200 Subject: [Idle-dev] [Python-Dev] IDLE contributors and committers In-Reply-To: References: <20100717133325.5f204ee9@pitrou.net> <4C41985A.4030201@holdenweb.com> Message-ID: <4C4CA7DA.8070103@v.loewis.de> >> There's no reason why Tal should be obstructed in his goal of making >> IDLE at least acceptable again. It's fairly obvious thaat there aren't >> any committers who have both the inclination /and/ the time to do this, >> so adding Tal (and other interested parties) as a developer makes a lot >> of sense. > > I would certainly accept this as a first step. Although I now use IDLE > much less than I have in previous years, I would be willing to put in > some time towards fixing the major current issues and integrating the > few polished enhancements. If you want commit access, please send me your ssh key. Regards, Martin From martin at v.loewis.de Sun Jul 25 23:25:36 2010 From: martin at v.loewis.de (=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=) Date: Sun, 25 Jul 2010 23:25:36 +0200 Subject: [Idle-dev] [Python-Dev] IDLE contributors and committers In-Reply-To: References: <20100717133325.5f204ee9@pitrou.net> <4C41985A.4030201@holdenweb.com> <4C41991A.9040103@voidspace.org.uk> Message-ID: <4C4CABD0.2080202@v.loewis.de> > Interested, yes. But until either a) I can commit patches, or b) there > is someone who will respond to commit review recommendations with "No, > here is why not" or "Yes, committed", I will work on other issues, such > as doc issues, for which I can get responses. If you are then still interested in getting commit access, please send me your SSH key. Regards, Martin From chaoslichen at gmail.com Tue Jul 27 05:47:13 2010 From: chaoslichen at gmail.com (Chas Leichner) Date: Mon, 26 Jul 2010 23:47:13 -0400 Subject: [Idle-dev] IDLE GSoC Extension Message-ID: I posted on this list at the start of the summer about my Google Summer of Code project. I've made a lot of progress and want to bring it to the community for some feedback. For people who missed a description, I am working on an extension to IDLE which will allow tutorials to be more interactive. It works by accepting specially annotated Python files which describe their own annotations. It then generates a trace of the execution, along with annotations and variables, storing it as a JSON file. I then made another type of window for stepping through the traces like a debugger and displaying the annotations at the appropriate lines.? I have gotten to the point where I have a working prototype for my project and would like to know where the IDLE developers see it fitting in with IDLE.? I don't know if it would fit in better as a built in additional feature, an optional extension, or somewhere in between. I would also appreciate any advice on how to integrate it better with the current class hierarchy (it is currently rather awkwardly grafted on) so I could get user interface issues addressed as soon as possible. If you want to take a look at what I've done so far, this is my repo: http://code.google.com/p/idlecarpentry/source/checkout. The .json files in the examples directory will bring up a trace window directly when you open them and the .py files will bring up the editor, as usual. Traces can be run from the editor window by selecting Run > Create Trace, annotations are pulled from any line starting with #> and applied to the first line of Python code which follows. I would love to hear any about any bugs you find or UI friction you encounter. I have been keeping a blog here http://cleichner.blogspot.com/, and will be posting a screencast to it tomorrow. Thanks, Chas