From tal.no.no.spam at gmail.com  Mon Dec  4 14:50:07 2006
From: tal.no.no.spam at gmail.com (Tal Einat)
Date: Mon, 4 Dec 2006 15:50:07 +0200
Subject: [Idle-dev] a debug problem
In-Reply-To: <7afdee2f0612040545r6096f75byc6d23b1cab4afc08@mail.gmail.com>
References: <456C51B7.1070800@planet.nl>
	<7afdee2f0612040545r6096f75byc6d23b1cab4afc08@mail.gmail.com>
Message-ID: <cd8c55c90612040550t7992128j724634d4515ded3@mail.gmail.com>

Joop,

I haven't been able to recreate your error.

Please specify your version of Python and OS, and explain the steps required
to recreate this error.

- Tal


On 28/11/06, *Joop Kaldeway* <joop.kaldeway at planet.nl> wrote:
>
>
> Dear idle-developers,.
>
> I have the following problem:
>
> I use the very simple program:
>
> class NewClass(object):
>
>    def __init__(self,element):
>        self.element = element
>
>    def __repr__(self):
>        return str(self.element)
>
> if __name__ == '__main__':
>
>    b = NewClass(3)
>    print b
>
>    raw_input("Press Enter to finish")
>
> It runs with output:
>
> 3
> Press Enter to finish
>
> But when I use te debugger and walk through the code step by step  I get
> an error:
>
> ...
> ...
> File "E:\Python25\lib\repr.py", line 34, in repr1
>    s = __builtin__.repr(x)
> File "F:\demo\NewClassDemo.py", line 24, in __repr__
>    return str(self.element)
> AttributeError: 'NewClass' object has no attribute 'element'
> [DEBUG ON]
> >>>
>
> Is it a bug in IDLE?
>
> Joop Kaldeway
>
>
>
> _______________________________________________
> IDLE-dev mailing list
> IDLE-dev at python.org
> http://mail.python.org/mailman/listinfo/idle-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/idle-dev/attachments/20061204/c9bece13/attachment.html 

From kbk at shore.net  Wed Dec  6 23:26:46 2006
From: kbk at shore.net (Kurt B. Kaiser)
Date: Wed, 06 Dec 2006 17:26:46 -0500
Subject: [Idle-dev] Erik Thompson's opinions on IDLE
In-Reply-To: <7afdee2f0611210816s165e0b48m19d2abfc5baa7963@mail.gmail.com>
	(Tal Einat's message of "Tue, 21 Nov 2006 18:16:16 +0200")
References: <7afdee2f0611210816s165e0b48m19d2abfc5baa7963@mail.gmail.com>
Message-ID: <87irgozmmx.fsf@hydra.bayview.thirdcreek.com>

"Tal Einat" <taleinat at gmail.com> writes:

> Nothing too extraordinary, but things we're hearing to often:
> * would like tabbed browsing of windows

Tk8.5 incorporating Tile may support this (ttkNotebook), along with
improved native look-and-feel.  Enhancements to tkinter would probably
be required.

For those on Linux or BSD, try using the Ion window manager.  This gives
you drag and drop Tabs.  When using Ion, I usually divide my screen into
two (or four) panes with the Shell on the left and a tabbed pane on the
right containing the code I'm working on.  (Reference code gets put in
the Shell pane as a Tab.)  The key point of Ion is that overlapping
windows are a fundamental GUI design mistake (though Ion3 allows them
:).  Tab switching is done by keyboard command as well as mouse.
Multiple desktops are supported; I put my browser fullscreen on a
different one.

If you're not using Ion, just minimize the windows you are not
currently using.  It's easy to have too many windows open; close them
and use Recent Files when necessary.

> * hasn't found the "recent files" feature

Recent Files is right there on the File menu, and can be torn off
for continuous visibility if the tabs in your window system don't
give you what you need.  Even better, the Windows menu can be torn
off and will update when you open or close windows.  The Zoom entry
allows you to toggle the height of the selected window.


> On the same note, What do you guys think of re-organizing our to-do
> list, asking around the Python community and see which feature requests
> rise?

We could do that.  But remember that IDLE is intended to be minimalist
in appearance (but not in functionality - the essential goodies should
be there for the experts to find) so that it won't be intimidating to
beginners, especially in an education environment.  Note that IDLE is
now suggested as an alternative to emacs for the MIT introductory
computing course.  MIT is switching from Scheme to Python for some
courses:

http://courses.csail.mit.edu/6.01/fall06/software/
http://courses.csail.mit.edu/6.01/
http://courses.csail.mit.edu/6.01/fall06/soar-manual/index

The first link leads to the Python IDLE page, which could really use
some updating!  Also, Daryl Harm's introduction is getting dated.  This
link will be many people's first taste of IDLE.

If you put out a call for features, you will get many requests, often
from people who haven't used Python or IDLE very long and are just
missing features they used in other environments.  Once they get used to
Python the need for these features diminishes.  For example, I rarely
use the debugger because print statements are usually faster given
IDLE's quick F5 turnaround.  Using the debugger can be fun, but I find
it's a rare case where in retrospect it was the most efficient solution.
(Not that our debugger couldn't be improved :)

When trying code folding I usually find that it gets in the way more
than it helps.  Use smaller modules or use the Class browser.
Incremental seach would help here, though the existing search is pretty
good.  I try to keep modules under 1200 lines.

It's a matter of drawing a distinction between what's useful and
practical for routine pure Python coding, and what's just bells,
whistles, 'would be nice to have', or copies of Visual Studio
or Eclipse features.

There are many Python IDEs and editors with a development policy of
adding lots of features.  In fact, most of them do this, since it keeps
the development team amused and differentiates them from the
competition.  Over time this leads to a very busy interface with
complicated menus, rows of buttons, and multiple status and side bars.
Some even incorporate GUI editors.

IDLE is perhaps the sole representative of an alternative approach and
therefore occupies an ecological niche!  It's a lot more powerful than
it appears to be.

It would be nice if we had an enhancement to the Options dialog which
provided an extension configurator.  Then we could easily add more
features for those who need them without cluttering the GUI.  Also, IDLE
extensions could be provided as third party contributions with a central
repository somewhere.

So the question is, what *essential* features are missing from IDLE?
What improvements in usability could be made to the ones we already have
without making the interface noisy, confusing, or chewing up valuable
screen space?  People often say they prefer other 'editors', but is there
really something missing from IDLE or are they just drawn to 'flash'?

My top items:

Incremental search (in a text entry widget in the bottom status bar).

Display/modification of sys.argv, probably in the status bar, or maybe
in a separate status bar which would appear when activated.

A solid way to copy code from the Shell to an edit window (smart
copy/paste doing tab conversion where necessary?).

A way to cut text in the shell without restarting it when it gets too
full (You lose the history when you restart the shell.  Maybe save
history across restarts?)

Any comments or votes on the above?

-- 
KBK

From fuzzyman at voidspace.org.uk  Wed Dec  6 23:36:58 2006
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Wed, 06 Dec 2006 22:36:58 +0000
Subject: [Idle-dev] Erik Thompson's opinions on IDLE
In-Reply-To: <87irgozmmx.fsf@hydra.bayview.thirdcreek.com>
References: <7afdee2f0611210816s165e0b48m19d2abfc5baa7963@mail.gmail.com>
	<87irgozmmx.fsf@hydra.bayview.thirdcreek.com>
Message-ID: <4577460A.4030302@voidspace.org.uk>

Kurt B. Kaiser wrote:
> "Tal Einat" <taleinat at gmail.com> writes:
[snip..]
> My top items:
> 

My two cents worth (possibly less).

IDLE achieves more than 90% of what I *need* from an IDE.

*The* reason I don't use it because it doesn't have tabbed windows. If I 
want several files open I end up with windows everywhere...

Even a faked tab like the IDLE dialogs would be fine. :-)


> Incremental search (in a text entry widget in the bottom status bar).
> 

+1 million. :-)

Not because I need it, but just because it's the best way.

Oh and a context menu with copy and paste on it would be nice.

That's about it...

Fuzzyman
http://www.voidspace.org.uk/python/index.shtml

> Display/modification of sys.argv, probably in the status bar, or maybe
> in a separate status bar which would appear when activated.
> 
> A solid way to copy code from the Shell to an edit window (smart
> copy/paste doing tab conversion where necessary?).
> 
> A way to cut text in the shell without restarting it when it gets too
> full (You lose the history when you restart the shell.  Maybe save
> history across restarts?)
> 
> Any comments or votes on the above?
> 



-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.409 / Virus Database: 268.15.9/573 - Release Date: 05/12/2006


From taleinat at gmail.com  Thu Dec  7 23:09:14 2006
From: taleinat at gmail.com (Tal Einat)
Date: Fri, 8 Dec 2006 00:09:14 +0200
Subject: [Idle-dev] Erik Thompson's opinions on IDLE
In-Reply-To: <4577460A.4030302@voidspace.org.uk>
References: <7afdee2f0611210816s165e0b48m19d2abfc5baa7963@mail.gmail.com>
	<87irgozmmx.fsf@hydra.bayview.thirdcreek.com>
	<4577460A.4030302@voidspace.org.uk>
Message-ID: <7afdee2f0612071409h993b98fo6416d9478ead8756@mail.gmail.com>

On 12/7/06, Michael Foord <fuzzyman at voidspace.org.uk> wrote:
>
> Kurt B. Kaiser wrote:
> > "Tal Einat" <taleinat at gmail.com> writes:
> [snip..]
> > My top items:
> >
>
> Even a faked tab like the IDLE dialogs would be fine. :-)


I've actually been working on this lately. I took to enhancing tabpage.py,
which is what the config dialog uses, and added some features:

* Tab panes with several rows of tabs (optional)
* Dynamic tab rows (optional) - rows of tabs are added or removed as needed,
currently according to a configurable number of tabs per row.
* Simpler, more Pythonic API
* Two placements methods for the inner pages - grid.raise and
pack/pack_forget. Each creates different behavior, and I couldn't decide
between them, so I made it configurable :)

The code still needs quite a bit of work, its very raw right now - I just
wanted to get it working for the extension configuration dialog I was
working on. Still, IMO its a huge improvement, and perhaps a good step in
the direction of reuseability?

(Oh yea - I also made a dialog for extension configuration. :D)

I hadn't mentioned it until now because interest was low and I'm still
working on it. If you like I can send the code / submit a patch.

> Incremental search (in a text entry widget in the bottom status bar).
> >
>
> +1 million. :-)
>
> Not because I need it, but just because it's the best way.


I've been working some on that too. I've created a Search Bar extension
which can be used instead of the Find & Replace dialogs. The search bar
shows a thin bar on the bottom of the window, with an entry box and the
usual options (wrap, direction, case-sensitive...). For replacing, the bar
is twice as thick, with two entries and extra replacement options (replace,
find next, replace all).

As for incremental search, currently the search bar's engine highlights the
hits (and jumps) only when a find command is given. Having this done for
every key typed should be easy based on this, but I haven't implemented it
yet.

> Display/modification of sys.argv, probably in the status bar, or maybe
> > in a separate status bar which would appear when activated.
> >


This is a very good direction IMO. One of the things IDLE is most useful for
is writing scripts, and being able to run them with a given sys.argv, easily
visible and changeable, would be bery helpful. I think this should be a
toggle-able option, to reduce clutter.


> > A solid way to copy code from the Shell to an edit window (smart
> > copy/paste doing tab conversion where necessary?).
> >


I believe the opposite direction - pasting code to the Shell - needs some
improvement too. For instance, pasting code with empty lines to the shell
doesn't work, you have to remove the empty lines first.

> A way to cut text in the shell without restarting it when it gets too
> > full (You lose the history when you restart the shell.  Maybe save
> > history across restarts?)


This is exactly what the Squeezer extension does! (along with not
having IDLE hang on large amounts of output)

Currently it only allow squeezing of stdout or stderr text, but I have
already discussed requests for it to be able to sqeeze arbitrarty text in
the shell, seems like it should be possible without too much of a hassle.

>
> > Any comments or votes on the above?
> >


+1 (or more?) on all of these.

IDLE has somewhat of a performance problem, which can be annoying. Sometimes
when you type fast, the text takes time to catch up with you. I know several
people who stopped using IDLE because of this. How about investiaging ways
to improve speed?

- Tal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/idle-dev/attachments/20061208/7fc497dd/attachment.html 

From fuzzyman at voidspace.org.uk  Thu Dec  7 23:18:32 2006
From: fuzzyman at voidspace.org.uk (Michael Foord)
Date: Thu, 07 Dec 2006 22:18:32 +0000
Subject: [Idle-dev] Erik Thompson's opinions on IDLE
In-Reply-To: <7afdee2f0612071409h993b98fo6416d9478ead8756@mail.gmail.com>
References: <7afdee2f0611210816s165e0b48m19d2abfc5baa7963@mail.gmail.com>	
	<87irgozmmx.fsf@hydra.bayview.thirdcreek.com>	
	<4577460A.4030302@voidspace.org.uk>
	<7afdee2f0612071409h993b98fo6416d9478ead8756@mail.gmail.com>
Message-ID: <45789338.3040806@voidspace.org.uk>

Tal Einat wrote:
> On 12/7/06, Michael Foord <fuzzyman at voidspace.org.uk> wrote:
>>
>> Kurt B. Kaiser wrote:
>> > "Tal Einat" <taleinat at gmail.com> writes:
>> [snip..]
>> > My top items:
>> >
>>
>> Even a faked tab like the IDLE dialogs would be fine. :-)
> 
> 
> I've actually been working on this lately. I took to enhancing tabpage.py,
> which is what the config dialog uses, and added some features:
> 
> * Tab panes with several rows of tabs (optional)
> * Dynamic tab rows (optional) - rows of tabs are added or removed as 
> needed,
> currently according to a configurable number of tabs per row.
> * Simpler, more Pythonic API
> * Two placements methods for the inner pages - grid.raise and
> pack/pack_forget. Each creates different behavior, and I couldn't decide
> between them, so I made it configurable :)
> 
> The code still needs quite a bit of work, its very raw right now - I just
> wanted to get it working for the extension configuration dialog I was
> working on. Still, IMO its a huge improvement, and perhaps a good step in
> the direction of reuseability?
> 
> (Oh yea - I also made a dialog for extension configuration. :D)
> 
> I hadn't mentioned it until now because interest was low and I'm still
> working on it. If you like I can send the code / submit a patch.
> 

I'd certainly like to have a look at it. It sounds great.

[snip..]
>> Display/modification of sys.argv, probably in the status bar, or maybe
>> > in a separate status bar which would appear when activated.
>> >
> 
> 
> This is a very good direction IMO. One of the things IDLE is most useful 
> for
> is writing scripts, and being able to run them with a given sys.argv, 
> easily
> visible and changeable, would be bery helpful. I think this should be a
> toggle-able option, to reduce clutter.
> 

It really annoys me that other IDEs don't give me the option to switch 
this off (like Wing and Pythonwin). Having to press another button to 
run a script sucks. (So keep it optional.)

All the best,


Fuzzyman
http://www.voidspace.org.uk/index2.shtml

[snip..]


-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.409 / Virus Database: 268.15.14/578 - Release Date: 07/12/2006


From taleinat at gmail.com  Fri Dec  8 02:38:35 2006
From: taleinat at gmail.com (Tal Einat)
Date: Fri, 8 Dec 2006 03:38:35 +0200
Subject: [Idle-dev] Erik Thompson's opinions on IDLE
In-Reply-To: <87irgozmmx.fsf@hydra.bayview.thirdcreek.com>
References: <7afdee2f0611210816s165e0b48m19d2abfc5baa7963@mail.gmail.com>
	<87irgozmmx.fsf@hydra.bayview.thirdcreek.com>
Message-ID: <7afdee2f0612071738q77712e80q8b7e7d87187c4b70@mail.gmail.com>

On 12/7/06, Kurt B. Kaiser <kbk at shore.net> wrote:
>
>
> My top items:
> [snip]
>
> Any comments or votes on the above?


I think GUI extension configuration should be added.

With some really strong extension in existence - AutoComplete, CallTips and
Squeezer to name my favorites - IMO this is essential to keeping IDLE
simple, easy and fun to use.

I've been working on this - I have a simple working prototype.

- Tal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/idle-dev/attachments/20061208/939e8367/attachment.htm 

From dblank at brynmawr.edu  Sat Dec 16 05:32:51 2006
From: dblank at brynmawr.edu (Douglas S. Blank)
Date: Fri, 15 Dec 2006 23:32:51 -0500 (EST)
Subject: [Idle-dev] Interruptable code?
Message-ID: <56174.68.34.179.248.1166243571.squirrel@webmail.brynmawr.edu>

I notice that in IDLE when running with -n (no processes) that:

>>> while 1: 1

can be stopped with control+c, but:

>>> while 1: None

cannot. I realize that this is true because the second example doesn't
cause anything to be written in the IDLE window, and the first does.

I see that running without the additional subprocess might make this a
hard bug to fix. But, is there something I can call like so:

>>> while 1: func()

where:

def func():
   # a call to check for control+c or update IDLE
   return None

Some additional data:

- I can't use idle with sub processes (because I want to interact with
Tkinter in a single thread)

- I tried printing nothing to the window:

>>> while 1: print '',

(note comma) but that actually does print something to the window. Can I
make these processes interruptable without printing something to the
window? I'm willing to alter IDLE if necessary.

Thanks for any hints,

-Doug

-- 
Douglas S. Blank
Associate Professor, Bryn Mawr College
http://cs.brynmawr.edu/~dblank/
Office: 610 526 601


From kbk at shore.net  Sat Dec 16 09:21:20 2006
From: kbk at shore.net (Kurt B. Kaiser)
Date: Sat, 16 Dec 2006 03:21:20 -0500
Subject: [Idle-dev] Interruptable code?
In-Reply-To: <56174.68.34.179.248.1166243571.squirrel@webmail.brynmawr.edu>
	(Douglas S. Blank's message of "Fri, 15 Dec 2006 23:32:51 -0500
	(EST)")
References: <56174.68.34.179.248.1166243571.squirrel@webmail.brynmawr.edu>
Message-ID: <87y7p8qmin.fsf@hydra.bayview.thirdcreek.com>

"Douglas S. Blank" <dblank at brynmawr.edu> writes:

> I notice that in IDLE when running with -n (no processes) that:
>
>>>> while 1: 1
>
> can be stopped with control+c, but:
>
>>>> while 1: None
>
> cannot. I realize that this is true because the second example doesn't
> cause anything to be written in the IDLE window, and the first does.

Yes. The cancel state is checked when PyShell.write() is called.

>
> I see that running without the additional subprocess might make this a
>hard bug to fix. But, is there something I can call like so:
>
>>>> while 1: func()
>
> where:
>
> def func():
>    # a call to check for control+c or update IDLE
>    return None

def func():
    while True:
          if flist.pyshell.canceled:
                break

while True: func()

(works w/o subprocess)


> Some additional data:
>
> - I can't use idle with sub processes (because I want to interact with
> Tkinter in a single thread)

If you run with the subprocess and construct Tkinter objects, they run in
a process separate from the IDLE GUI.  This is an advantage in most cases!

One of the objectives for implementing the subprocess was to separate
the IDLE GUI from the user code.  The user code can be interrupted even
in 

while True: pass

(But IDLE Windows has problems with killing user code which is blocked.)

-- 
KBK

From dblank at brynmawr.edu  Sat Dec 16 15:31:22 2006
From: dblank at brynmawr.edu (Douglas S. Blank)
Date: Sat, 16 Dec 2006 09:31:22 -0500 (EST)
Subject: [Idle-dev] Interruptable code?
In-Reply-To: <87y7p8qmin.fsf@hydra.bayview.thirdcreek.com>
References: <56174.68.34.179.248.1166243571.squirrel@webmail.brynmawr.edu>
	<87y7p8qmin.fsf@hydra.bayview.thirdcreek.com>
Message-ID: <56741.68.34.179.248.1166279482.squirrel@webmail.brynmawr.edu>


On Sat, December 16, 2006 3:21 am, Kurt B. Kaiser said:

[snip]

> def func():
>     while True:
>           if flist.pyshell.canceled:
>                 break
>
> while True: func()
>
> (works w/o subprocess)

Thanks! That will do it.

>> - I can't use idle with sub processes (because I want to interact with
>> Tkinter in a single thread)
>
> If you run with the subprocess and construct Tkinter objects, they run in
> a process separate from the IDLE GUI.  This is an advantage in most cases!

Yes, I realize that. But there is one important case where it is not:
interactively creating and using Tkinter and/or the Python prompt. For
example, being able to create a window and interactively type in commands
to alter the window. Maybe I am using Tkinter incorrectly from Idle? When
I type:

>>> import Tkinter
>>> tk = Tkinter.Tk()

in idle -n (or raw Python), I get to interactively manuipulate Tk windows.
When run in idle with subprocesses, it doesn't show any windows until a
mainloop() (or similar method) is called.

This "problem" has caused John Zelle to have to add code to his
graphics.py so that Tkinter will work the same in both methods of running
Idle. See:

http://mcsp.wartburg.edu/zelle/python/index.html

and look at graphics.py.

Is there an option I'm not aware of? (BTW, I do what a solution to work on
Windows, Mac, and Linux).

Thanks again!

-Doug

> One of the objectives for implementing the subprocess was to separate
> the IDLE GUI from the user code.  The user code can be interrupted even
> in
>
> while True: pass
>
> (But IDLE Windows has problems with killing user code which is blocked.)
>
> --
> KBK
>


-- 
Douglas S. Blank
Associate Professor, Bryn Mawr College
http://cs.brynmawr.edu/~dblank/
Office: 610 526 601


From taleinat at gmail.com  Sat Dec 16 16:15:16 2006
From: taleinat at gmail.com (Tal Einat)
Date: Sat, 16 Dec 2006 17:15:16 +0200
Subject: [Idle-dev] Interruptable code?
In-Reply-To: <56741.68.34.179.248.1166279482.squirrel@webmail.brynmawr.edu>
References: <56174.68.34.179.248.1166243571.squirrel@webmail.brynmawr.edu>
	<87y7p8qmin.fsf@hydra.bayview.thirdcreek.com>
	<56741.68.34.179.248.1166279482.squirrel@webmail.brynmawr.edu>
Message-ID: <7afdee2f0612160715h44140727i8a051008b125d373@mail.gmail.com>

On 12/16/06, Douglas S. Blank <dblank at brynmawr.edu> wrote:

>
> On Sat, December 16, 2006 3:21 am, Kurt B. Kaiser said:
>
> >> - I can't use idle with sub processes (because I want to interact with
> >> Tkinter in a single thread)
> >
> > If you run with the subprocess and construct Tkinter objects, they run
> in
> > a process separate from the IDLE GUI.  This is an advantage in most
> cases!
>
> Yes, I realize that. But there is one important case where it is not:
> interactively creating and using Tkinter and/or the Python prompt. For
> example, being able to create a window and interactively type in commands
> to alter the window. Maybe I am using Tkinter incorrectly from Idle? When
> I type:
>
> >>> import Tkinter
> >>> tk = Tkinter.Tk()
>
> in idle -n (or raw Python), I get to interactively manuipulate Tk windows.
> When run in idle with subprocesses, it doesn't show any windows until a
> mainloop() (or similar method) is called.


 This always works for me:

import thread
import Tkinter
root = Tkinter.Tk()
...
thread.start_new_thread(root.mainloop, ())

This way you can even kill the mainloop without killing IDLE.

Hooking onto IDLE's GUI mainloop isn't a very good option IMO. It's very
useful when you're debugging IDLE itself, but otherwise it's a source
of inconsistent behavior and weird bugs.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/idle-dev/attachments/20061216/e0c0a627/attachment.html 

From dblank at brynmawr.edu  Sat Dec 16 16:59:49 2006
From: dblank at brynmawr.edu (Douglas S. Blank)
Date: Sat, 16 Dec 2006 10:59:49 -0500 (EST)
Subject: [Idle-dev] Interruptable code?
In-Reply-To: <7afdee2f0612160715h44140727i8a051008b125d373@mail.gmail.com>
References: <56174.68.34.179.248.1166243571.squirrel@webmail.brynmawr.edu> 
	<87y7p8qmin.fsf@hydra.bayview.thirdcreek.com> 
	<56741.68.34.179.248.1166279482.squirrel@webmail.brynmawr.edu>
	<7afdee2f0612160715h44140727i8a051008b125d373@mail.gmail.com>
Message-ID: <20182.68.34.179.248.1166284789.squirrel@webmail.brynmawr.edu>

On Sat, December 16, 2006 10:15 am, Tal Einat said:

[snip]

>  This always works for me:
>
> import thread
> import Tkinter
> root = Tkinter.Tk()
> ...
> thread.start_new_thread(root.mainloop, ())
>
> This way you can even kill the mainloop without killing IDLE.
>
> Hooking onto IDLE's GUI mainloop isn't a very good option IMO. It's very
> useful when you're debugging IDLE itself, but otherwise it's a source
> of inconsistent behavior and weird bugs.

Thanks, that's useful. But it isn't really an option for teaching Intro to
CS. It would be nice if Tkinter worked this way if it were started up from
inside idle. Given that I don't want to introduce this kind of complexity,
I guess I can either use Zelle's library or use "idle -n".

Thanks again,

-Doug

-- 
Douglas S. Blank
Associate Professor, Bryn Mawr College
http://cs.brynmawr.edu/~dblank/
Office: 610 526 601


From dblank at brynmawr.edu  Mon Dec 18 05:33:35 2006
From: dblank at brynmawr.edu (Douglas S. Blank)
Date: Sun, 17 Dec 2006 23:33:35 -0500 (EST)
Subject: [Idle-dev] Interruptable code?
In-Reply-To: <87y7p8qmin.fsf@hydra.bayview.thirdcreek.com>
References: <56174.68.34.179.248.1166243571.squirrel@webmail.brynmawr.edu>
	<87y7p8qmin.fsf@hydra.bayview.thirdcreek.com>
Message-ID: <3497.68.34.179.248.1166416415.squirrel@webmail.brynmawr.edu>

Just thought I'd post the details of what worked for me in interrupting a
loop in idle with no subprocesses and no print statements on WindowsXP.

Checking on PyShell.flist.pyshell.canceled did not work, because it
appears that "canceled" doesn't get set until "write()" is called.

But with that hint, I just add a bunch of write's in my code, like so:

def func():
    PyShell.flist.pyshell.write("")
    return None

Then I can control+c the following:

>>> while 1: func()

If you remove the write(), you won't be able to stop the program (short of
killing IDLE).

(I actually made it a bit smarter, so that it can run outside of IDLE, too.)

Thanks, again, for the hints.

-Doug

On Sat, December 16, 2006 3:21 am, Kurt B. Kaiser said:
> "Douglas S. Blank" <dblank at brynmawr.edu> writes:
>
>> I notice that in IDLE when running with -n (no processes) that:
>>
>>>>> while 1: 1
>>
>> can be stopped with control+c, but:
>>
>>>>> while 1: None
>>
>> cannot. I realize that this is true because the second example doesn't
>> cause anything to be written in the IDLE window, and the first does.
>
> Yes. The cancel state is checked when PyShell.write() is called.
>
>>
>> I see that running without the additional subprocess might make this a
>>hard bug to fix. But, is there something I can call like so:
>>
>>>>> while 1: func()
>>
>> where:
>>
>> def func():
>>    # a call to check for control+c or update IDLE
>>    return None
>
> def func():
>     while True:
>           if flist.pyshell.canceled:
>                 break
>
> while True: func()
>
> (works w/o subprocess)
>
>
>> Some additional data:
>>
>> - I can't use idle with sub processes (because I want to interact with
>> Tkinter in a single thread)
>
> If you run with the subprocess and construct Tkinter objects, they run in
> a process separate from the IDLE GUI.  This is an advantage in most cases!
>
> One of the objectives for implementing the subprocess was to separate
> the IDLE GUI from the user code.  The user code can be interrupted even
> in
>
> while True: pass
>
> (But IDLE Windows has problems with killing user code which is blocked.)
>
> --
> KBK
>


-- 
Douglas S. Blank
Associate Professor, Bryn Mawr College
http://cs.brynmawr.edu/~dblank/
Office: 610 526 601


From kbk at shore.net  Tue Dec 19 05:18:47 2006
From: kbk at shore.net (Kurt B. Kaiser)
Date: Mon, 18 Dec 2006 23:18:47 -0500
Subject: [Idle-dev] Interruptable code?
In-Reply-To: <3497.68.34.179.248.1166416415.squirrel@webmail.brynmawr.edu>
	(Douglas S. Blank's message of "Sun, 17 Dec 2006 23:33:35 -0500
	(EST)")
References: <56174.68.34.179.248.1166243571.squirrel@webmail.brynmawr.edu>
	<87y7p8qmin.fsf@hydra.bayview.thirdcreek.com>
	<3497.68.34.179.248.1166416415.squirrel@webmail.brynmawr.edu>
Message-ID: <87mz5ka57c.fsf@hydra.bayview.thirdcreek.com>

"Douglas S. Blank" <dblank at brynmawr.edu> writes:

> Just thought I'd post the details of what worked for me in interrupting a
> loop in idle with no subprocesses and no print statements on WindowsXP.

For those tuning in late, we are discussing running IDLE without the
subprocess.  This is not the recommended way to run IDLE.


> Checking on PyShell.flist.pyshell.canceled did not work, because it
> appears that "canceled" doesn't get set until "write()" is called.

It seemed to be working for me.  The 'canceled' attribute was being
accessed.

But I think I was mistaken and was 'interrupting' the code before it was
actually running: I needed another <enter> :-)

Digging deeper:

pyshell.canceled is set by PyShell.cancel_callback().  But this callback
isn't being run because Tk isn't servicing its events (the GUI is
frozen) while the non-printing program is running as part of
PyShell.enter_callback().  The event loop won't resume until that
callback is completed.

If the program should print (via a re-directed stdout -> PseudoFile ->
OutputWindow -> tkinter text widget) then OutputWindow.write() calls
self.text.update().

That update causes the event loop to run.  The pending cancel_callback
sets pyshell.canceled, which is then picked up when PyShell.write()
completes, and a KeyboardInterrupt is generated.

A solution is to update Tkinter.  Include this in your module:
=====================
try:
    shell = idlelib.PyShell.flist.pyshell
    root = idlelib.PyShell.root

    def break_check():
        root.update()
        if shell.canceled:
            raise KeyboardInterrupt
        
except NameError: # idlelib not in namespace: running in subprocess
    def break_check():
        # subprocess responds to KBI
        pass
====================

and use break_check in your code where it might loop.

while True: break_check()



Another solution when running without the subprocess is to hit a Ctrl-C in
the console window from which you started IDLE.  (On Windows, you would
need to start IDLE from a command window.  cd to ..../Lib/idlelib and

..\..\python .\PyShell.py

)

The ModifiedInterpreter.runcode() has called

exec code in self.locals

and the interrupt in the console window is received by python (which
without the subprocess is the only python involved).  There's an except:
statement in runcode() which traps this and causes IDLE to reset.


> But with that hint, I just add a bunch of write's in my code, like so:
>
> def func():
>     PyShell.flist.pyshell.write("")
>     return None
>
> Then I can control+c the following:
>
>>>> while 1: func()
>
> If you remove the write(), you won't be able to stop the program (short of
> killing IDLE).


This is also a reasonable solution.  A little magical, but reasonable :-)


All of this is needed because without the subprocess, it's a little tricky
to interrupt user code without interrupting IDLE itself.

-- 
KBK

From mick.lumsdon at gmail.com  Tue Dec 19 16:03:02 2006
From: mick.lumsdon at gmail.com (Mick Lumsdon)
Date: Wed, 20 Dec 2006 00:03:02 +0900
Subject: [Idle-dev] IDLE crashes on OS X
Message-ID: <5ac3267b0612190703n6c2f32dck6b6b076dc97febc5@mail.gmail.com>

Hello,

I am having a major problem using IDLE on my imac: it crashes as soon
as I select 'preferences' (on IDLE 1.2, Python 2.5)  or 'configure
IDLE' (IDLE 1.1.4, Python 2.4.4)

Terminal reports a "Segmentation fault" upon the crash.

My system is OS X v 10.4.8, iMac G5, 1 GB ram, and seems otherwise stable.

Please, can anyone tell me is there a known cause for this behaviour?
Should I direct this query elsewhere?

Kind regards, Mick L

From kbk at shore.net  Thu Dec 21 21:56:13 2006
From: kbk at shore.net (Kurt B. Kaiser)
Date: Thu, 21 Dec 2006 15:56:13 -0500
Subject: [Idle-dev] IDLE crashes on OS X
In-Reply-To: <5ac3267b0612190703n6c2f32dck6b6b076dc97febc5@mail.gmail.com>
	(Mick Lumsdon's message of "Wed, 20 Dec 2006 00:03:02 +0900")
References: <5ac3267b0612190703n6c2f32dck6b6b076dc97febc5@mail.gmail.com>
Message-ID: <87irg50xzm.fsf@hydra.bayview.thirdcreek.com>

"Mick Lumsdon" <mick.lumsdon at gmail.com> writes:

> I am having a major problem using IDLE on my imac: it crashes as soon
> as I select 'preferences' (on IDLE 1.2, Python 2.5)  or 'configure
> IDLE' (IDLE 1.1.4, Python 2.4.4)
>
> Terminal reports a "Segmentation fault" upon the crash.
>
> My system is OS X v 10.4.8, iMac G5, 1 GB ram, and seems otherwise stable.
>
> Please, can anyone tell me is there a known cause for this behaviour?
> Should I direct this query elsewhere?

The best thing would be to enter a bug on the Python Tracker:

http://sourceforge.net/tracker/?atid=105470&group_id=5470&func=browse

I don't have a way of testing on the Mac.

IDLE is written in pure Python, so it's either something in Python itself,
the installation on OS X, or a problem with your imac.  I haven't heard
about a problem like this.

-- 
KBK

From ronaldoussoren at mac.com  Fri Dec 22 07:59:19 2006
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Fri, 22 Dec 2006 07:59:19 +0100
Subject: [Idle-dev] IDLE crashes on OS X
In-Reply-To: <87irg50xzm.fsf@hydra.bayview.thirdcreek.com>
References: <5ac3267b0612190703n6c2f32dck6b6b076dc97febc5@mail.gmail.com>
	<87irg50xzm.fsf@hydra.bayview.thirdcreek.com>
Message-ID: <B8F3AA41-51F8-4565-B559-18ECDC1B2FD7@mac.com>


On 21 Dec, 2006, at 21:56, Kurt B. Kaiser wrote:

> "Mick Lumsdon" <mick.lumsdon at gmail.com> writes:
>
>> I am having a major problem using IDLE on my imac: it crashes as soon
>> as I select 'preferences' (on IDLE 1.2, Python 2.5)  or 'configure
>> IDLE' (IDLE 1.1.4, Python 2.4.4)
>>
>> Terminal reports a "Segmentation fault" upon the crash.
>>
>> My system is OS X v 10.4.8, iMac G5, 1 GB ram, and seems otherwise  
>> stable.
>>
>> Please, can anyone tell me is there a known cause for this behaviour?
>> Should I direct this query elsewhere?
>
> The best thing would be to enter a bug on the Python Tracker:
>
> http://sourceforge.net/tracker/?atid=105470&group_id=5470&func=browse

Feel free to assign the bug to me.

>
> I don't have a way of testing on the Mac.
>
> IDLE is written in pure Python, so it's either something in Python  
> itself,
> the installation on OS X, or a problem with your imac.  I haven't  
> heard
> about a problem like this.

Me neither.

Mick, do you have a Tk.framework in /Library/Frameworks? If so, could  
you open /Library/Frameworks/Tk.framework/Versions/Current/ 
Resources/"Wish Shell" and tell us the Tcl/Tk versions (found in the  
about dialog).

Ronald

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3562 bytes
Desc: not available
Url : http://mail.python.org/pipermail/idle-dev/attachments/20061222/3f309a7b/attachment.bin 

From altern2 at gmail.com  Tue Dec 26 13:38:38 2006
From: altern2 at gmail.com (altern)
Date: Tue, 26 Dec 2006 13:38:38 +0100
Subject: [Idle-dev] error with IDLE on debian
Message-ID: <459117CE.1030609@gmail.com>

Hi

Hi, I wrote with this problem to the general Python mailing list but I 
did not get any answer so I decided to email to the IDLE-dev list. My 
problem is that when i try to run IDLE on my debian laptop I get this error.

$ idle
Traceback (most recent call last):
   File "/usr/bin/idle", line 5, in ?
     main()
   File "idlelib/PyShell.py", line 1359, in main
   File "idlelib/FileList.py", line 44, in new
   File "idlelib/PyShell.py", line 105, in __init__
   File "idlelib/EditorWindow.py", line 111, in __init__
   File "/usr/lib/python2.4/lib-tk/Tkinter.py", line 2764, in __init__
     Widget.__init__(self, master, 'text', cnf, kw)
   File "/usr/lib/python2.4/lib-tk/Tkinter.py", line 1865, in __init__
     self.tk.call(
_tkinter.TclError: expected integer but got "`100"

Few weeks ago IDLE worked fine, I dont really know what could be causing 
the error.

I am running Debian unstable with python 2.4.4, tcl8.4, tk8.4, python-tk
24.4-1 and IDLE 2.4.4-2. I already tried to reinstall IDLE, tk and tcl
and python-tk but that did not solve anything, i keep getting the same
error.

any ideas?

thanks

enrike


From sspatz at kcnet.com  Wed Dec 27 17:14:13 2006
From: sspatz at kcnet.com (Saul Spatz)
Date: Wed, 27 Dec 2006 10:14:13 -0600
Subject: [Idle-dev] Newbie Question
Message-ID: <45929BD5.6010500@kcnet.com>

I am rather new to both python and IDLE.  The references to IDLE at 
www.python.org seem sadly out-of-date.  I have a couple of simple 
enhancements I would like to make to IDLE that are not likely to be of 
general interest.  (I want to use IDLE in teaching, and I want to save 
the sessions, both user input and IDLE output.  I would like IDLE to 
remember where I saved the last session and default to that directory, 
and I would like it to prompt me if I close the IDLE window without 
having saved the session.)   It seems like these should be easy to 
program, but I can't find the IDLE source. 

Where is it, please?  I assume that I am allowed modify it just for my 
own use.

Thanks

From taleinat at gmail.com  Wed Dec 27 18:12:59 2006
From: taleinat at gmail.com (Tal Einat)
Date: Wed, 27 Dec 2006 19:12:59 +0200
Subject: [Idle-dev] matplotlib incompatibility
Message-ID: <7afdee2f0612270912o16fc2d88kc70348457f49b2e6@mail.gmail.com>

>From matplotlib's homepage:
http://matplotlib.sourceforge.net/backends.html#TkAgg

In general, TkAgg is known to work with

   - python
   - idle -n (set tk.PYTHONINSPECT : True in
matplotlibrc<http://matplotlib.sourceforge.net/matplotlibrc>
   - IPython

TkAgg is known not work with:

   - SciTE
   - pythonw
   - Pythonwin
   - idle

Both of the latter shells fail with a RuntimeError "abnormal program
termination".


Does anyone know why this is?
Can the problem(s) be overcome?
Is any work being done to overcome the incompatibility?

- Tal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/idle-dev/attachments/20061227/4340eb76/attachment.html 

From taleinat at gmail.com  Wed Dec 27 18:23:43 2006
From: taleinat at gmail.com (Tal Einat)
Date: Wed, 27 Dec 2006 19:23:43 +0200
Subject: [Idle-dev] Newbie Question
In-Reply-To: <45929BD5.6010500@kcnet.com>
References: <45929BD5.6010500@kcnet.com>
Message-ID: <7afdee2f0612270923l79a4698o614ae9eee16d46a5@mail.gmail.com>

On 12/27/06, Saul Spatz <sspatz at kcnet.com> wrote:
>
> I am rather new to both python and IDLE.  The references to IDLE at
> www.python.org seem sadly out-of-date.  I have a couple of simple
> enhancements I would like to make to IDLE that are not likely to be of
> general interest.  (I want to use IDLE in teaching, and I want to save
> the sessions, both user input and IDLE output.  I would like IDLE to
> remember where I saved the last session and default to that directory,
> and I would like it to prompt me if I close the IDLE window without
> having saved the session.)   It seems like these should be easy to
> program, but I can't find the IDLE source.
>
> Where is it, please?  I assume that I am allowed modify it just for my
> own use.


Overcourse you may.

IDLE is written in Python, so you can simply edit its code, wherever your
Python installation is.
Just look in \Lib\idlelib\.
(For instance, on Windows: C:\Python25\Lib\idlelib\)

In addition, IDLE's source is in Python's SVN:
http://www.python.org/dev/faq#subversion-svn
(here too, look under Lib\idlelib\.)

In addition, we'd be glad to hear any about any features you find missing or
suggestions for improvement regarding IDLE.

Good luck!

- Tal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/idle-dev/attachments/20061227/51403024/attachment.htm 

From taleinat at gmail.com  Thu Dec 28 00:13:42 2006
From: taleinat at gmail.com (Tal Einat)
Date: Thu, 28 Dec 2006 01:13:42 +0200
Subject: [Idle-dev] Erik Thompson's opinions on IDLE
In-Reply-To: <7afdee2f0612271512u5585365bu88e676f8786a5806@mail.gmail.com>
References: <7afdee2f0611210816s165e0b48m19d2abfc5baa7963@mail.gmail.com>
	<87irgozmmx.fsf@hydra.bayview.thirdcreek.com>
	<7afdee2f0612271512u5585365bu88e676f8786a5806@mail.gmail.com>
Message-ID: <7afdee2f0612271513p37585494m32e32aeefa365f5c@mail.gmail.com>

On 12/7/06, Kurt B. Kaiser <kbk at shore.net> wrote:
>
>
> There are many Python IDEs and editors with a development policy of
> adding lots of features.  In fact, most of them do this, since it keeps
> the development team amused and differentiates them from the
> competition.  Over time this leads to a very busy interface with
> complicated menus, rows of buttons, and multiple status and side bars.
> Some even incorporate GUI editors.
>
> IDLE is perhaps the sole representative of an alternative approach and
> therefore occupies an ecological niche!  It's a lot more powerful than
> it appears to be.
>
> It would be nice if we had an enhancement to the Options dialog which
> provided an extension configurator.  Then we could easily add more
> features for those who need them without cluttering the GUI.  Also, IDLE
> extensions could be provided as third party contributions with a central
> repository somewhere.
>
> So the question is, what *essential* features are missing from IDLE?
> What improvements in usability could be made to the ones we already have
> without making the interface noisy, confusing, or chewing up valuable
> screen space?  People often say they prefer other 'editors', but is there
> really something missing from IDLE or are they just drawn to 'flash'?
>
> My top items:
>
> Incremental search (in a text entry widget in the bottom status bar).
>
> Display/modification of sys.argv, probably in the status bar, or maybe
> in a separate status bar which would appear when activated.
>
> A solid way to copy code from the Shell to an edit window (smart
> copy/paste doing tab conversion where necessary?).
>
> A way to cut text in the shell without restarting it when it gets too
> full (You lose the history when you restart the shell.  Maybe save
> history across restarts?)
>
> Any comments or votes on the above?


A major feature I miss is a "Goto definition" function. I spend far too much
time manually searching for function and class definitions when working with
IDLE.

- Tal
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/idle-dev/attachments/20061228/eb2c4632/attachment.htm 

From kbk at shore.net  Sat Dec 30 07:00:37 2006
From: kbk at shore.net (Kurt B. Kaiser)
Date: Sat, 30 Dec 2006 01:00:37 -0500
Subject: [Idle-dev] error with IDLE on debian
In-Reply-To: <459117CE.1030609@gmail.com> (altern2@gmail.com's message of
	"Tue, 26 Dec 2006 13:38:38 +0100")
References: <459117CE.1030609@gmail.com>
Message-ID: <878xgp53ei.fsf@hydra.bayview.thirdcreek.com>

altern <altern2 at gmail.com> writes:

> Hi, I wrote with this problem to the general Python mailing list but I 
> did not get any answer so I decided to email to the IDLE-dev list. My 
> problem is that when i try to run IDLE on my debian laptop I get this error.
>
> $ idle
> Traceback (most recent call last):
>    File "/usr/bin/idle", line 5, in ?
>      main()
>    File "idlelib/PyShell.py", line 1359, in main
>    File "idlelib/FileList.py", line 44, in new
>    File "idlelib/PyShell.py", line 105, in __init__
>    File "idlelib/EditorWindow.py", line 111, in __init__
>    File "/usr/lib/python2.4/lib-tk/Tkinter.py", line 2764, in __init__
>      Widget.__init__(self, master, 'text', cnf, kw)
>    File "/usr/lib/python2.4/lib-tk/Tkinter.py", line 1865, in __init__
>      self.tk.call(
> _tkinter.TclError: expected integer but got "`100"
>
> Few weeks ago IDLE worked fine, I dont really know what could be causing 
> the error.
>
> I am running Debian unstable with python 2.4.4, tcl8.4, tk8.4, python-tk
> 24.4-1 and IDLE 2.4.4-2. I already tried to reinstall IDLE, tk and tcl
> and python-tk but that did not solve anything, i keep getting the same
> error.
>
> any ideas?

Try setting aside (i.e. rename) your .idlerc directory and restart IDLE.

-- 
KBK