headers
Robert | 2 Feb 2011 22:58
Picon
Gravatar

IDLE going forward

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
Permalink | Reply | 12 comments |
headers
Corey Richardson | 2 Feb 2011 23:18
Gravatar

Re: IDLE going forward

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
(Continue reading)

Permalink | Reply | 3 comments |
headers
Douglas S. Blank | 2 Feb 2011 23:45
Picon

Re: IDLE going forward

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
(Continue reading)

Permalink | Reply | 7 comments |
headers
Corey Richardson | 3 Feb 2011 00:18
Gravatar

Re: IDLE going forward


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
(Continue reading)

Permalink | Reply | 0 comments |
headers
Robert | 3 Feb 2011 00:22
Picon
Gravatar

Re: IDLE going forward

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
(Continue reading)

Permalink | Reply | 2 comments |
headers
Robert | 3 Feb 2011 00:23
Picon
Gravatar

Re: IDLE going forward

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!
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Bruce Sherwood | 3 Feb 2011 00:22
Picon
Favicon

Re: IDLE going forward

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 <dblank <at> brynmawr.edu> 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
(Continue reading)

Permalink | Reply | 2 comments |
headers
Ned Deily | 3 Feb 2011 05:55
Picon
Favicon
Gravatar

Re: IDLE going forward

In article 
<AANLkTinUg1sPNhH7L39g9qwkmp=Uux_QDtrK119tK=Ks <at> mail.gmail.com>,
 Bruce Sherwood <Bruce_Sherwood <at> ncsu.edu> 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.

--

--
(Continue reading)

Permalink | Reply | 1 comment |
headers
Ned Deily | 3 Feb 2011 06:13
Picon
Favicon
Gravatar

Re: IDLE going forward

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
Permalink | Reply | 0 comments |
headers
Terry Reedy | 3 Feb 2011 07:24
Picon
Favicon

Re: IDLE going forward

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
>
(Continue reading)

Permalink | Reply | 0 comments |

Gmane