From sigzero at gmail.com Wed Feb 2 22:58:37 2011 From: sigzero at gmail.com (Robert) Date: Wed, 2 Feb 2011 16:58:37 -0500 Subject: [Idle-dev] IDLE going forward Message-ID: It was suggested in another Python newsgroup that IDLE has flaws. Yes, I know, hard to believe that software has flaws, however, out of that was born a desire to clean up the code cruft etc. in IDLE. Two things that came out generally were: * Update the UI (use ttk widgets etc.) * More tests and automate testing * Clean up the code What else would you like to see? I was said that Python (and IDLE) are going to Mercurial at some point, so maybe that would be a good time to start the effort. It will be a bit for me. I have some learning to do before I try and tackle this. I think it would be a good way for me to continue to learn about Python, unit testing, UI design and code refactoring. So chime in with your suggestions! Thought: Should this just be an effort for IDLE in P3 going forward so that focus can be had? -- Robert From kb1pkl at aim.com Wed Feb 2 23:18:41 2011 From: kb1pkl at aim.com (Corey Richardson) Date: Wed, 02 Feb 2011 17:18:41 -0500 Subject: [Idle-dev] IDLE going forward In-Reply-To: References: Message-ID: <4D49D841.7050104@aim.com> On 2/2/2011 4:58 PM, Robert wrote: > It was suggested in another Python newsgroup that IDLE has flaws. Yes, > I know, hard to believe that software has flaws, however, out of that > was born a desire to clean up the code cruft etc. in IDLE. > > Two things that came out generally were: > > * Update the UI (use ttk widgets etc.) > * More tests and automate testing > * Clean up the code > > What else would you like to see? I was said that Python (and IDLE) are > going to Mercurial at some point, so maybe that would be a good time > to start the effort. > > It will be a bit for me. I have some learning to do before I try and > tackle this. I think it would be a good way for me to continue to > learn about Python, unit testing, UI design and code refactoring. Quite a bit of learning for me as well! Mostly it's just that I've never done much with ttk or testing, but I'm glad to learn. > > So chime in with your suggestions! I think that is quite the list already. After we (whoever we may be) get that list done, we can think of other things. > > Thought: Should this just be an effort for IDLE in P3 going forward so > that focus can be had? Considering that all non-bugfix changes aren't being accepted for Python 2, this would be strictly Python 3. From dblank at brynmawr.edu Wed Feb 2 23:45:42 2011 From: dblank at brynmawr.edu (Douglas S. Blank) Date: Wed, 02 Feb 2011 17:45:42 -0500 Subject: [Idle-dev] IDLE going forward In-Reply-To: References: Message-ID: <4D49DE96.3020606@brynmawr.edu> On 02/02/2011 04:58 PM, Robert wrote: > It was suggested in another Python newsgroup that IDLE has flaws. Yes, I > know, hard to believe that software has flaws, however, out of that was > born a desire to clean up the code cruft etc. in IDLE. As a long time IDLE user, I don't think that the issue is that IDLE has flaws. What is missing is a group of people that use it everyday who have a vision about making it better than it currently is. > Two things that came out generally were: > > * Update the UI (use ttk widgets etc.) > * More tests and automate testing > * Clean up the code > > What else would you like to see? I was said that Python (and IDLE) are > going to Mercurial at some point, so maybe that would be a good time to > start the effort. > > It will be a bit for me. I have some learning to do before I try and > tackle this. I think it would be a good way for me to continue to learn > about Python, unit testing, UI design and code refactoring. > > So chime in with your suggestions! I've stopped using IDLE, so I don't know if some of these issues have been addressed in the latest versions, but here are some things that were issues: * needs a stable interface for plugins (it seemed like each version changed slightly and our extensions kept breaking) * more hooks for plugins * needed a way to run the code in editor window without restarting the shell (some code has start-up code that should not have to be re-run each time you want to load the program) * control+p and alt+p (print and previous) were too similar and I kept printing the entire history * allow one to select a printer before printing * ability to clear the shell window * allow IDLE to startup with either shell or editor * Don't show the weird, scary message about Personal Firewall subprocessing and loopbacks. That is not a good way to introduce people to computing! * Allow more than one idle to be run at same time * command-line history persistent between sessions * some weird cursor positions in shell. home should take you to a place after prompt, not before. * cutting and pasting from shell to window could remove the >>> prompts * menu items not intuitive for beginners * more options with a context-sensitive right-mouse-click IDLE is very nice, but it could be developed into a finally-tuned product. Good luck! -Doug > Thought: Should this just be an effort for IDLE in P3 going forward so > that focus can be had? > -- Douglas S. Blank Associate Professor, Computer Science, Bryn Mawr College http://cs.brynmawr.edu/~dblank (610)526-6501 From kb1pkl at aim.com Thu Feb 3 00:18:02 2011 From: kb1pkl at aim.com (Corey Richardson) Date: Wed, 02 Feb 2011 18:18:02 -0500 Subject: [Idle-dev] IDLE going forward In-Reply-To: <4D49DE96.3020606@brynmawr.edu> References: <4D49DE96.3020606@brynmawr.edu> Message-ID: <4D49E62A.9020202@aim.com> On 2/2/2011 5:45 PM, Douglas S. Blank wrote: > [snip] > I've stopped using IDLE, so I don't know if some of these issues have > been addressed in the latest versions, but here are some things that > were issues: > > * needs a stable interface for plugins (it seemed like each version > changed slightly and our extensions kept breaking) > > * more hooks for plugins > > * needed a way to run the code in editor window without restarting the > shell (some code has start-up code that should not have to be re-run > each time you want to load the program) > > * control+p and alt+p (print and previous) were too similar and I kept > printing the entire history > > * allow one to select a printer before printing > > * ability to clear the shell window > > * allow IDLE to startup with either shell or editor > > * Don't show the weird, scary message about Personal Firewall > subprocessing and loopbacks. That is not a good way to introduce > people to computing! > > * Allow more than one idle to be run at same time > > * command-line history persistent between sessions > > * some weird cursor positions in shell. home should take you to a > place after prompt, not before. > > * cutting and pasting from shell to window could remove the >>> prompts > > * menu items not intuitive for beginners > > * more options with a context-sensitive right-mouse-click > > IDLE is very nice, but it could be developed into a finally-tuned > product. > > Good luck! > > -Doug That looks like a good list. Another good goal would be to make it so less people say "Don't use IDLE" and decrease the general dislike. A bit of a lofty goal, but they must have good reasons to not use idle, otherwise they wouldn't say that...right? ;-) From sigzero at gmail.com Thu Feb 3 00:22:20 2011 From: sigzero at gmail.com (Robert) Date: Wed, 2 Feb 2011 18:22:20 -0500 Subject: [Idle-dev] IDLE going forward References: <4D49D841.7050104@aim.com> Message-ID: On 2011-02-02 17:18:41 -0500, Corey Richardson said: > On 2/2/2011 4:58 PM, Robert wrote: >> It was suggested in another Python newsgroup that IDLE has flaws. Yes, >> I know, hard to believe that software has flaws, however, out of that >> was born a desire to clean up the code cruft etc. in IDLE. >> >> Two things that came out generally were: >> >> * Update the UI (use ttk widgets etc.) >> * More tests and automate testing >> * Clean up the code >> >> What else would you like to see? I was said that Python (and IDLE) are >> going to Mercurial at some point, so maybe that would be a good time >> to start the effort. >> >> It will be a bit for me. I have some learning to do before I try and >> tackle this. I think it would be a good way for me to continue to >> learn about Python, unit testing, UI design and code refactoring. > > Quite a bit of learning for me as well! Mostly it's just that I've never > done much with ttk or testing, but I'm glad to learn. > >> >> So chime in with your suggestions! > I think that is quite the list already. After we (whoever we may be) get > that list done, we can think of other things. >> >> Thought: Should this just be an effort for IDLE in P3 going forward so >> that focus can be had? > Considering that all non-bugfix changes aren't being accepted for Python > 2, this would be strictly Python 3. I was thinking that as well. The Python class that I am taking is all P3 and has Tkinter stuff in it. :-) -- Robert From sigzero at gmail.com Thu Feb 3 00:23:18 2011 From: sigzero at gmail.com (Robert) Date: Wed, 2 Feb 2011 18:23:18 -0500 Subject: [Idle-dev] IDLE going forward References: <4D49DE96.3020606@brynmawr.edu> Message-ID: On 2011-02-02 17:45:42 -0500, Douglas S. Blank said: > On 02/02/2011 04:58 PM, Robert wrote: >> It was suggested in another Python newsgroup that IDLE has flaws. Yes, I >> know, hard to believe that software has flaws, however, out of that was >> born a desire to clean up the code cruft etc. in IDLE. > > As a long time IDLE user, I don't think that the issue is that IDLE has > flaws. What is missing is a group of people that use it everyday who > have a vision about making it better than it currently is. I should have put suggested in quotes. :-) > >> Two things that came out generally were: >> >> * Update the UI (use ttk widgets etc.) >> * More tests and automate testing >> * Clean up the code >> >> What else would you like to see? I was said that Python (and IDLE) are >> going to Mercurial at some point, so maybe that would be a good time to >> start the effort. >> >> It will be a bit for me. I have some learning to do before I try and >> tackle this. I think it would be a good way for me to continue to learn >> about Python, unit testing, UI design and code refactoring. >> >> So chime in with your suggestions! > > I've stopped using IDLE, so I don't know if some of these issues have > been addressed in the latest versions, but here are some things that > were issues: > > * needs a stable interface for plugins (it seemed like each version > changed slightly and our extensions kept breaking) > > * more hooks for plugins > > * needed a way to run the code in editor window without restarting the > shell (some code has start-up code that should not have to be re-run > each time you want to load the program) > > * control+p and alt+p (print and previous) were too similar and I kept > printing the entire history > > * allow one to select a printer before printing > > * ability to clear the shell window > > * allow IDLE to startup with either shell or editor > > * Don't show the weird, scary message about Personal Firewall > subprocessing and loopbacks. That is not a good way to introduce people > to computing! > > * Allow more than one idle to be run at same time > > * command-line history persistent between sessions > > * some weird cursor positions in shell. home should take you to a place > after prompt, not before. > > * cutting and pasting from shell to window could remove the >>> prompts > > * menu items not intuitive for beginners > > * more options with a context-sensitive right-mouse-click > > IDLE is very nice, but it could be developed into a finally-tuned product. > > Good luck! > > -Doug Thanks for the input Doug. -- Robert From Bruce_Sherwood at ncsu.edu Thu Feb 3 00:22:35 2011 From: Bruce_Sherwood at ncsu.edu (Bruce Sherwood) Date: Wed, 2 Feb 2011 16:22:35 -0700 Subject: [Idle-dev] IDLE going forward In-Reply-To: <4D49DE96.3020606@brynmawr.edu> References: <4D49DE96.3020606@brynmawr.edu> Message-ID: You may or not be aware that there is a "VIDLE" distributed with VPython (vpython.org) that incorporates many improvements made by David Scherer and Guilhermo Polo (during a recent Google Summer of Code) that are supposed to be moved into the standard Python distribution. In fact, Guido asked that despite the freeze, these changes be put into Python 2.7. But I don't know when this might happen. On Wed, Feb 2, 2011 at 3:45 PM, Douglas S. Blank wrote: > * allow IDLE to startup with either shell or editor This is a configuration option in the standard IDLE. VIDLE has some additional useful configuration options: If file has never been saved, Prompt to Save or No prompt. Many of us find this extremely useful, because it means one can write a tiny program and run it instantly, without the distraction of having to save the file first. It provides for whole programs the immediacy otherwise available only in the shell. If file has been saved before, Prompt to Save or No prompt. Similar to the previous, but it makes sure you've saved the file to some known place before you go on. On first error, Bring shell forward or Do nothing. This is very important for novice users who often fill the screen with the edit window and then don't see an error message. > > * Don't show the weird, scary message about Personal Firewall subprocessing > and loopbacks. That is not a good way to introduce people to computing! Eliminated from VIDLE. Bruce Sherwood From nad at acm.org Thu Feb 3 05:55:24 2011 From: nad at acm.org (Ned Deily) Date: Wed, 02 Feb 2011 20:55:24 -0800 Subject: [Idle-dev] IDLE going forward References: <4D49DE96.3020606@brynmawr.edu> Message-ID: In article , Bruce Sherwood wrote: > You may or not be aware that there is a "VIDLE" distributed with > VPython (vpython.org) that incorporates many improvements made by > David Scherer and Guilhermo Polo (during a recent Google Summer of > Code) that are supposed to be moved into the standard Python > distribution. In fact, Guido asked that despite the freeze, these > changes be put into Python 2.7. But I don't know when this might > happen. It will start happening sometime (soon, I hope) after Python 3.2 goes out the door, which should happen in about two weeks. Unfortunately, there has been a lot of last-minute firefighting in Python 3.2 IDLE, particularly on Mac OS X 10.6 when using the new Cocoa-based version of Tk 8.5. It would be great to have more testing there of either the traditional 32-bit OS X installer (from python.org) which uses either the Apple-suppliedTk 8.4 (included with OS X 10.4 through 10.6) or ActiveState Tk 8.4. Or, on 10.6 only, the 64-bit/32-bit installer which requires the latest ActiveState Tk 8.5. There is preliminary, pre-release info here: http://www.python.org/download/releases/3.2/ http://www.python.org/download/mac/tcltk/ Once 3.2 is released, I plan to work on getting the VIDLE enhancements into the next maintenance releases, 2.7.2 and 3.2.1. -- Ned Deily, nad at acm.org From nad at acm.org Thu Feb 3 06:13:27 2011 From: nad at acm.org (Ned Deily) Date: Wed, 02 Feb 2011 21:13:27 -0800 Subject: [Idle-dev] IDLE going forward References: <4D49DE96.3020606@brynmawr.edu> Message-ID: The suggestions so far are good. To reduce the chances that they are forgotten, it would be better to submit them as either bug fix or enhancement requests to the Python issue tracker (http://bugs.python.org/). One area not mentioned but of critical importance is the lack in the standard library of a test suite for IDLE. Right now it is very difficult to know when things are broken or breaking because of the lack of tests. Making such a test suite presents some "interesting" challenges, though. The current python test suite does very little automated GUI interface testing so some new cross-platform infrastructure to do so would need to be added, preferably in a way that can be added to the source code tree without creating any licensing issues (i.e. not GPL). Another challenge is to do so in a way that ideally covers all of the primary IDLE execution environments: Windows, native Mac OS X, and Unix/X11. If you have ideas or experience in this area, your contributions would be especially welcome. -- Ned Deily, nad at acm.org From tjreedy at udel.edu Thu Feb 3 07:24:15 2011 From: tjreedy at udel.edu (Terry Reedy) Date: Thu, 03 Feb 2011 01:24:15 -0500 Subject: [Idle-dev] IDLE going forward In-Reply-To: <4D49DE96.3020606@brynmawr.edu> References: <4D49DE96.3020606@brynmawr.edu> Message-ID: On 2/2/2011 5:45 PM, Douglas S. Blank wrote: > I've stopped using IDLE, so I don't know if some of these issues have > been addressed in the latest versions, but here are some things that > were issues: > > * needs a stable interface for plugins (it seemed like each version > changed slightly and our extensions kept breaking) > > * more hooks for plugins > > * needed a way to run the code in editor window without restarting the > shell (some code has start-up code that should not have to be re-run > each time you want to load the program) > > * control+p and alt+p (print and previous) were too similar and I kept > printing the entire history > > * allow one to select a printer before printing > > * ability to clear the shell window > > * allow IDLE to startup with either shell or editor > > * Don't show the weird, scary message about Personal Firewall > subprocessing and loopbacks. That is not a good way to introduce people > to computing! > > * Allow more than one idle to be run at same time > > * command-line history persistent between sessions > > * some weird cursor positions in shell. home should take you to a place > after prompt, not before. > > * cutting and pasting from shell to window could remove the >>> prompts > > * menu items not intuitive for beginners > > * more options with a context-sensitive right-mouse-click > > IDLE is very nice, but it could be developed into a finally-tuned product. > > Good luck! I have some of the same wishes. I am saving this list. -- Terry Jan Reedy From tjreedy at udel.edu Thu Feb 3 07:29:23 2011 From: tjreedy at udel.edu (Terry Reedy) Date: Thu, 03 Feb 2011 01:29:23 -0500 Subject: [Idle-dev] IDLE going forward In-Reply-To: References: <4D49D841.7050104@aim.com> Message-ID: On 2/2/2011 6:22 PM, Robert wrote: > On 2011-02-02 17:18:41 -0500, Corey Richardson said: >> Considering that all non-bugfix changes aren't being accepted for Python >> 2, this would be strictly Python 3. > > I was thinking that as well. The Python class that I am taking is all P3 > and has Tkinter stuff in it. :-) Since IDLE is not really library code, but an application, one could argue that the no new feature rule should not necessarily apply. But I personally would only make that argument for 3.2. I will ask on pydev when there is code to argue over. I no no interest at present in backporting to 2.7. One reasone is that once 3.2 is out, I think most new Python programmers should start with that. -- Terry Jan Reedy From Bruce_Sherwood at ncsu.edu Thu Feb 3 07:52:03 2011 From: Bruce_Sherwood at ncsu.edu (Bruce Sherwood) Date: Wed, 2 Feb 2011 23:52:03 -0700 Subject: [Idle-dev] IDLE going forward In-Reply-To: References: <4D49DE96.3020606@brynmawr.edu> Message-ID: Okay, I'll raise the priority on trying to get VPython to run on Python 3.2. Bruce On Wed, Feb 2, 2011 at 9:55 PM, Ned Deily wrote: > In article > , > ?Bruce Sherwood wrote: > >> You may or not be aware that there is a "VIDLE" distributed with >> VPython (vpython.org) that incorporates many improvements made by >> David Scherer and Guilhermo Polo (during a recent Google Summer of >> Code) that are supposed to be moved into the standard Python >> distribution. In fact, Guido asked that despite the freeze, these >> changes be put into Python 2.7. But I don't know when this might >> happen. > > It will start happening sometime (soon, I hope) after Python 3.2 goes > out the door, which should happen in about two weeks. ?Unfortunately, > there has been a lot of last-minute firefighting in Python 3.2 IDLE, > particularly on Mac OS X 10.6 when using the new Cocoa-based version of > Tk 8.5. ?It would be great to have more testing there of either the > traditional 32-bit OS X installer (from python.org) which uses either > the Apple-suppliedTk 8.4 (included with OS X 10.4 through 10.6) or > ActiveState Tk 8.4. ?Or, on 10.6 only, the 64-bit/32-bit installer which > requires the latest ActiveState Tk 8.5. ?There is preliminary, > pre-release info here: > > http://www.python.org/download/releases/3.2/ > http://www.python.org/download/mac/tcltk/ > > Once 3.2 is released, I plan to work on getting the VIDLE enhancements > into the next maintenance releases, 2.7.2 and 3.2.1. > > -- > ?Ned Deily, > ?nad at acm.org > > _______________________________________________ > IDLE-dev mailing list > IDLE-dev at python.org > http://mail.python.org/mailman/listinfo/idle-dev > From sigzero at gmail.com Thu Feb 3 22:54:33 2011 From: sigzero at gmail.com (Robert) Date: Thu, 3 Feb 2011 16:54:33 -0500 Subject: [Idle-dev] IDLE going forward References: <4D49D841.7050104@aim.com> Message-ID: On 2011-02-03 01:29:23 -0500, Terry Reedy said: > On 2/2/2011 6:22 PM, Robert wrote: >> On 2011-02-02 17:18:41 -0500, Corey Richardson said: > >>> Considering that all non-bugfix changes aren't being accepted for Python >>> 2, this would be strictly Python 3. >> >> I was thinking that as well. The Python class that I am taking is all P3 >> and has Tkinter stuff in it. :-) > > Since IDLE is not really library code, but an application, one could > argue that the no new feature rule should not necessarily apply. But I > personally would only make that argument for 3.2. I will ask on pydev > when there is code to argue over. > > I no no interest at present in backporting to 2.7. One reasone is that > once 3.2 is out, I think most new Python programmers should start with that. I would agree with going with 3.x going forward. I am going to be taking some classes and P3 is all they teach. :) -- Robert