IDLE going forward

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

IDLE going forward

Robert H
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


_______________________________________________
IDLE-dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/idle-dev
Reply | Threaded
Open this post in threaded view
|

Re: IDLE going forward

Corey Richardson
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.


_______________________________________________
IDLE-dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/idle-dev
Reply | Threaded
Open this post in threaded view
|

Re: IDLE going forward

Doug Blank-3
In reply to this post by Robert H
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
_______________________________________________
IDLE-dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/idle-dev
Reply | Threaded
Open this post in threaded view
|

Re: IDLE going forward

Corey Richardson


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? ;-)
_______________________________________________
IDLE-dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/idle-dev
Reply | Threaded
Open this post in threaded view
|

Re: IDLE going forward

Robert H
In reply to this post by Corey Richardson
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


_______________________________________________
IDLE-dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/idle-dev
Reply | Threaded
Open this post in threaded view
|

Re: IDLE going forward

Bruce Sherwood
In reply to this post by Doug Blank-3
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 <[hidden email]> 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
_______________________________________________
IDLE-dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/idle-dev
Reply | Threaded
Open this post in threaded view
|

Re: IDLE going forward

Robert H
In reply to this post by Doug Blank-3
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


_______________________________________________
IDLE-dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/idle-dev
Reply | Threaded
Open this post in threaded view
|

Re: IDLE going forward

Ned Deily
In reply to this post by Bruce Sherwood
In article
<AANLkTinUg1sPNhH7L39g9qwkmp=Uux_QDtrK119tK=[hidden email]>,
 Bruce Sherwood <[hidden email]> 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,
 [hidden email]

_______________________________________________
IDLE-dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/idle-dev
Reply | Threaded
Open this post in threaded view
|

Re: IDLE going forward

Ned Deily
In reply to this post by Doug Blank-3
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,
 [hidden email]

_______________________________________________
IDLE-dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/idle-dev
Reply | Threaded
Open this post in threaded view
|

Re: IDLE going forward

Terry Reedy
In reply to this post by Doug Blank-3
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

_______________________________________________
IDLE-dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/idle-dev
Reply | Threaded
Open this post in threaded view
|

Re: IDLE going forward

Terry Reedy
In reply to this post by Robert H
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

_______________________________________________
IDLE-dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/idle-dev
Reply | Threaded
Open this post in threaded view
|

Re: IDLE going forward

Bruce Sherwood
In reply to this post by Ned Deily
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 <[hidden email]> wrote:

> In article
> <AANLkTinUg1sPNhH7L39g9qwkmp=Uux_QDtrK119tK=[hidden email]>,
>  Bruce Sherwood <[hidden email]> 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,
>  [hidden email]
>
> _______________________________________________
> IDLE-dev mailing list
> [hidden email]
> http://mail.python.org/mailman/listinfo/idle-dev
>
_______________________________________________
IDLE-dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/idle-dev
Reply | Threaded
Open this post in threaded view
|

Re: IDLE going forward

Robert H
In reply to this post by Terry Reedy
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


_______________________________________________
IDLE-dev mailing list
[hidden email]
http://mail.python.org/mailman/listinfo/idle-dev