From spiridenok at tut.by  Thu Jan  8 15:38:09 2009
From: spiridenok at tut.by (Dima S)
Date: Thu, 08 Jan 2009 16:38:09 +0200
Subject: [Idle-dev] Breakpoint is not reached in multithreading application
Message-ID: <web-125116026@speedy.tutby.com>

Hi all,

I try to use IDLE for debugging my multithreading python application.
In my application i have the following class:

class DataMonitor( threading.Thread ):
     '''Updates data with regular frequency'''
     _update_frequency_in_sec = 0.5

     def __init__ ( self, update_funcs, data ):
         threading.Thread.__init__( self )
         self._update_funcs = update_funcs
         self._data = data
         self._keep_running = True

     def run(self):
         '''Start data monitoring'''
         while self._keep_running:
             self._update_data()
             print "i'm running"
             time.sleep( self._update_frequency_in_sec )

An object of this class is created from the main thread and is stored there.

When i set breakpoints in the code that is executed in the main thread, they 
are reached with no problems.
When i set breakpoints in the while loop of the run() method of my thread 
class DataMonitor (at the line with print statement), the breakpoint is 
never reached. However, the application keeps running and i get a lot of 
"i'm running" messages in the python shell of IDLE.

My configuration:
SunOS wsasd179 5.8 Generic_117350-18 sun4u sparc SUNW,Sun-Blade-1500
Python 2.5.1 (r251:54863, Aug  6 2008, 14:27:55)
[GCC 3.4.3] on sunos5

Thanks for any help on my problem!

Regards, DimaS
-------------- next part --------------
An embedded message was scrubbed...
From: "Dima S" <spiridenok at tut.by>
Subject: Breakpoint is not reached in multithreading application
Date: Thu, 08 Jan 2009 16:35:14 +0200
Size: 1928
URL: <http://mail.python.org/pipermail/idle-dev/attachments/20090108/781aee1e/attachment.eml>

From clockworksaint at gmail.com  Thu Jan 22 14:38:43 2009
From: clockworksaint at gmail.com (Weeble)
Date: Thu, 22 Jan 2009 13:38:43 +0000
Subject: [Idle-dev] Shift+HOME selects wrong text
Message-ID: <13e3f9930901220538p5664ad2au954796c7b67bfd38@mail.gmail.com>

When I press shift and home, IDLE raises an exception and/or selects
the wrong text. For example, enter some text, then hold down shift and
use the cursor to select some of it and position the cursor in the
middle of a line. Then press shift+home. The problem seems to occur in
EditorWindow.py in home_callback. When it does this:
    first = self.text.index(dest)
    last = self.text.index("anchor")
There is no mark called "anchor". There appears instead to be one
called "tk::anchor.44486744.44486984.text", although I would guess
that the numbers are not fixed. If you press shift+home with no
selection, it will create a mark called "anchor", but all that means
is that the selection behaviour gets even stranger, since the home-key
handling is using "anchor" but the standard cursor actions are using
the weirdly named one.

I'm using: Python 2.6, Tk 8.5, IDLE 2.6
I'm running the 32-bit version on 64-bit Vista. I installed it from an
installer on the Python website.

When I get home I can test it on Ubuntu and see if I see the same thing.

I think perhaps this might have been introduced with the fix for this
bug: http://bugs.python.org/issue3851

From clockworksaint at gmail.com  Thu Jan 22 22:45:12 2009
From: clockworksaint at gmail.com (Weeble)
Date: Thu, 22 Jan 2009 21:45:12 +0000
Subject: [Idle-dev] Shift+HOME selects wrong text
In-Reply-To: <13e3f9930901220538p5664ad2au954796c7b67bfd38@mail.gmail.com>
References: <13e3f9930901220538p5664ad2au954796c7b67bfd38@mail.gmail.com>
Message-ID: <13e3f9930901221345m2009758bo518912a7bfdb8fa6@mail.gmail.com>

Okay, I got home and it works fine here, but that appears to be
because Python is using Tk 8.4 on my install of Ubuntu. Looking at
text.tcl, it seems that 8.5 has changed the name of the anchor mark to
be private and unique to each widget:

# Note that the 'anchor' is implemented programmatically using
# a text widget mark, and uses a name that will be unique for each
# text widget (even when there are multiple peers).  Currently the
# anchor is considered private to Tk, hence the name 'tk::anchor$w'.

I think the following method should fix it, but I haven't had a chance
to try it on Tk 8.5 yet. It at least seems just as good as the other
method on Tk 8.4:

In EditorWindow.py, replace this:
        if (event.state&1) == 0:
            # shift not pressed
            self.text.tag_remove("sel", "1.0", "end")
        else:
            if not self.text.index("sel.first"):
                self.text.mark_set("anchor","insert")

            first = self.text.index(dest)
            last = self.text.index("anchor")

            if self.text.compare(first,">",last):
                first,last = last,first

            self.text.tag_remove("sel", "1.0", "end")
            self.text.tag_add("sel", first, last)

With this:
        if (event.state&1) == 0:
            # shift not pressed
            self.text.tag_remove("sel", "1.0", "end")
        else:
            self.text.tk.call('tk::TextKeySelect', self.text._w, dest)

This retains the behaviour where Home toggles between the first
non-whitespace character and the start of the line. I'll try it out on
Tk 8.5 at work tomorrow.

On Thu, Jan 22, 2009 at 1:38 PM, Weeble <clockworksaint at gmail.com> wrote:
> When I press shift and home, IDLE raises an exception and/or selects
> the wrong text. For example, enter some text, then hold down shift and
> use the cursor to select some of it and position the cursor in the
> middle of a line. Then press shift+home. The problem seems to occur in
> EditorWindow.py in home_callback. When it does this:
>    first = self.text.index(dest)
>    last = self.text.index("anchor")
> There is no mark called "anchor". There appears instead to be one
> called "tk::anchor.44486744.44486984.text", although I would guess
> that the numbers are not fixed. If you press shift+home with no
> selection, it will create a mark called "anchor", but all that means
> is that the selection behaviour gets even stranger, since the home-key
> handling is using "anchor" but the standard cursor actions are using
> the weirdly named one.
>
> I'm using: Python 2.6, Tk 8.5, IDLE 2.6
> I'm running the 32-bit version on 64-bit Vista. I installed it from an
> installer on the Python website.
>
> When I get home I can test it on Ubuntu and see if I see the same thing.
>
> I think perhaps this might have been introduced with the fix for this
> bug: http://bugs.python.org/issue3851
>

From clockworksaint at gmail.com  Sun Jan 25 22:13:47 2009
From: clockworksaint at gmail.com (Weeble)
Date: Sun, 25 Jan 2009 21:13:47 +0000
Subject: [Idle-dev] Other places to discuss IDLE?
Message-ID: <13e3f9930901251313m4dbc7018q556d7ef7dc138ec2@mail.gmail.com>

It does seem a bit quiet in here, so I was wondering if there's
somewhere better to discuss IDLE? Is it quiet because there aren't
many developers interested in/working on IDLE, or because they're all
elsewhere? I'm interested in helping out by fixing bugs, but I'm
worried that my effort will be wasted.

From Bruce_Sherwood at ncsu.edu  Sun Jan 25 22:52:49 2009
From: Bruce_Sherwood at ncsu.edu (Bruce Sherwood)
Date: Sun, 25 Jan 2009 16:52:49 -0500
Subject: [Idle-dev] Other places to discuss IDLE?
In-Reply-To: <13e3f9930901251313m4dbc7018q556d7ef7dc138ec2@mail.gmail.com>
References: <13e3f9930901251313m4dbc7018q556d7ef7dc138ec2@mail.gmail.com>
Message-ID: <497CDF31.7090103@ncsu.edu>

I'll comment that David Scherer, who in 2000 made a major upgrade to 
IDLE in connection with his creation of VPython (vpython.org), has 
recently done some work off to the side to make needed improvements to 
IDLE, and not just bug fixes. I think he got discouraged by there 
seeming to be no real path for making changes that would make it into 
the regular Python distribution, so he has gone in the direction of 
building (again) an alternative version of IDLE that we would package as 
"VIDLE" with distribution of VPython. This initiative is however on hold 
at the moment because he has personal business to attend to at this 
time. I do expect him to get back to this work within a few months.

Here is an informal list of problems (BAS is me, DS is Scherer):

On Mac, BAS notes sluggishness of the scrollbar slider getting behind 
the mouse in a serious way, even hanging up.

There's the issue of DS patch to IDLE to make a VPython go away when you 
re-run, which DS proposed to the IDLE-dev list with little support; 
without this fix it is annoying and intrusive that the following doesn't 
work: Run from IDLE. VPython graphics window appears. Make a source edit 
and press and run again. The old VPython graphics window should 
disappear and the new one start up, but instead you get two graphics 
windows.

There's the annoying problem that right-click on a .py file on Windows 
to edit with IDLE lets you run a VPython program only once; close the 
graphics window and IDLE exits.

On the Mac, nonactive windows don't display their selections.  This 
makes find and replace utterly unusable in IDLE, since the item to be 
replaced isn't highlighted!

There is no options/preferences window on the Mac!

The Mac key combinations need work.

On the Mac, mouse control often gets messed up after switching away and 
back to IDLE.

On all platforms, the prompt to save before running is unnecessary; 
instead unsaved changes should be committed to a temp file but the 
unsaved status should not be changed, so the prompt appears on close or 
exit.

On all platforms, system library tracebacks should be suppressed by default.

The shell window should scroll to hide previous runs when a program is 
executed.  (The "Restart" line should be just above the top of the window)

The shell window should possibly come forward or otherwise "signal" 
itself (the appropriate behavior may vary by platform) the first time 
something is printed to stderr.  Care needs to be taken to not let this 
become annoying. This is a VERY serious problem for students, who see 
their program not run but don't know why because the error message is 
hidden.

If we suppress "system" portions of execution errors, maybe there should 
be a configuration option to unsuppress them during development.

Mac users expect to be able to scroll on a trackpad by dragging two 
fingers; the current Mac IDLE doesn't deal with this.

Scott David Daniels commented on Mac IDLE problem of misplaced editing 
position:
To get evidence of this -- start idle from a terminal window
with a "python25 -m idlelib.idle" where python25 is the path to your
python executable. You get output on stderr each time the mouse drops
a line of mouse positioning.

Jim Mueller reports:
-------------------
2754      6 days ago       Mac version of IDLE doesn't scroll as 
expected       open      alextrob
http://bugs.python.org/issue2754

3549      6 days ago       Missing IDLE Preferences on Mac       pending 
      pchew
http://bugs.python.org/issue3549

After reading the first one, I can verify that I see this effect too.

The second one states that the Options->Configure menu has
become IDLE->Preferences on the mac, but there was a bug in how they
checked the Tk version.  So it should bite you if you have a version of
Tk < 8.4.10.  It states that this was fixed on Friday and is in the
trunk and backported to the 2.6 and 3.1 versions of Python.  (3.1?)

Anyway below is my previous message, which is probably out of date now.

I have tried out idle from both the current Enthought and the one that
comes with MacPython.  The only things I see are:

1) If I open a new window, or open a file, occasionally I get an error

RCNE SendEventToEventTarget (suom Moved               ) failed, -50

This does not happen every time, and maybe it could happen selecting
other menu items.  I haven't tried everything, and it is intermittent
on those where I do see it.  I can't give an impression of whether it
occurs more frequently in one distribution than another, because after
playing for 5 minutes on each, I only have a handful of instances
total.  Any comparison would no be statistically significant, but it
does not seem to be a large problem.  Of course that might just be my
hardware.

2) If I click in one window and then back in source window, Focus is
changed to the source window but the cursor position is still where it
was when I was last in that window.  Once focus has been shifted to
that window, cursor move properly when I click on text.  This is a
"feature" that I see all the time on Macs.  When I have two browser
windows open I click on a button in one, it has no effect unless that
window already has the focus.  This is sometimes annoying for me in
that I don't want to have to click twice to get something to happen.
Other times I am happy that the button I just happen to click on while
trying to bring a window to the front didn't actually register the
click.

3) I haven't been able to get the scrollbar problem to occur, but
again if it is an intermittent problem, perhaps I just haven't tried
long enough.

4) The reason that the new Enthought distribution has a "Configure
IDLE" menu option is that they threw out the IDLE.app.  Instead they
provide a simple shell script, ".command" which then runs   "/Library/
Frameworks/Python.framework/Versions/Current/bin/idle" in a console
window.  So the configure problem is in IDLE.app, not idle.

Later, more from Jim Mueller:
The patch works.
In macosxSupport.py, if you change the line
     if tkversion >= '8.4.14':
to
     if map(int, tkversion.split('.')) >= (8, 4, 14):
then you get an IDLE->Preferences menu, which contains all the 
configuration stuff.

I haven't checked the 2.5.4 version of MacPython, but since this
change only went into the repository on Friday.  It might not be in the
bundle.
-------------------------

Bruce Sherwood

Weeble wrote:
> It does seem a bit quiet in here, so I was wondering if there's
> somewhere better to discuss IDLE? Is it quiet because there aren't
> many developers interested in/working on IDLE, or because they're all
> elsewhere? I'm interested in helping out by fixing bugs, but I'm
> worried that my effort will be wasted.
> _______________________________________________
> IDLE-dev mailing list
> IDLE-dev at python.org
> http://mail.python.org/mailman/listinfo/idle-dev

From ronaldoussoren at mac.com  Mon Jan 26 06:52:44 2009
From: ronaldoussoren at mac.com (Ronald Oussoren)
Date: Mon, 26 Jan 2009 06:52:44 +0100
Subject: [Idle-dev] Other places to discuss IDLE?
In-Reply-To: <497CDF31.7090103@ncsu.edu>
References: <13e3f9930901251313m4dbc7018q556d7ef7dc138ec2@mail.gmail.com>
	<497CDF31.7090103@ncsu.edu>
Message-ID: <2702B3A3-5B77-41E1-8C16-C055FFA5DA1F@mac.com>


On 25 Jan, 2009, at 22:52, Bruce Sherwood wrote:

> I'll comment that David Scherer, who in 2000 made a major upgrade to  
> IDLE in connection with his creation of VPython (vpython.org), has  
> recently done some work off to the side to make needed improvements  
> to IDLE, and not just bug fixes. I think he got discouraged by there  
> seeming to be no real path for making changes that would make it  
> into the regular Python distribution, so he has gone in the  
> direction of building (again) an alternative version of IDLE that we  
> would package as "VIDLE" with distribution of VPython. This  
> initiative is however on hold at the moment because he has personal  
> business to attend to at this time. I do expect him to get back to  
> this work within a few months.

AFAIK the best way to get changes into the python.org tree is to file  
bugreports with patches.

>
>
> Here is an informal list of problems (BAS is me, DS is Scherer):
>
> On Mac, BAS notes sluggishness of the scrollbar slider getting  
> behind the mouse in a serious way, even hanging up.

Patches are greatly appreciated.

[...]

> On the Mac, nonactive windows don't display their selections.  This  
> makes find and replace utterly unusable in IDLE, since the item to  
> be replaced isn't highlighted!

Likewise.

>
>
> There is no options/preferences window on the Mac!

There is a bug in all released versions of 2.6 that surpress the  
options/preferences menu unless you install a custom Tcl/Tk framework  
instead of relying on the system install of Tcl/Tk.

>
> The Mac key combinations need work.
>
> On the Mac, mouse control often gets messed up after switching away  
> and back to IDLE.
>
[...]

> Mac users expect to be able to scroll on a trackpad by dragging two  
> fingers; the current Mac IDLE doesn't deal with this.

[...]

>
>
> Scott David Daniels commented on Mac IDLE problem of misplaced  
> editing position:
> To get evidence of this -- start idle from a terminal window
> with a "python25 -m idlelib.idle" where python25 is the path to your
> python executable. You get output on stderr each time the mouse drops
> a line of mouse positioning.
>
> Jim Mueller reports:
> -------------------
> 2754      6 days ago       Mac version of IDLE doesn't scroll as  
> expected       open      alextrob
> http://bugs.python.org/issue2754
>
> 3549      6 days ago       Missing IDLE Preferences on Mac        
> pending      pchew
> http://bugs.python.org/issue3549
>
> After reading the first one, I can verify that I see this effect too.
>
> The second one states that the Options->Configure menu has
> become IDLE->Preferences on the mac, but there was a bug in how they
> checked the Tk version.  So it should bite you if you have a version  
> of
> Tk < 8.4.10.  It states that this was fixed on Friday and is in the
> trunk and backported to the 2.6 and 3.1 versions of Python.  (3.1?)

That's correct. The fix is in the 2.6 maintenance branch and the  
Python 2.x and Python 3.x trunks. I  haven't had time to backport to  
the 3.0 maintenance branch yet.

>
>
> Anyway below is my previous message, which is probably out of date  
> now.
>
> I have tried out idle from both the current Enthought and the one that
> comes with MacPython.  The only things I see are:
>
> 1) If I open a new window, or open a file, occasionally I get an error
>
> RCNE SendEventToEventTarget (suom Moved               ) failed, -50


>
>
> This does not happen every time, and maybe it could happen selecting
> other menu items.  I haven't tried everything, and it is intermittent
> on those where I do see it.  I can't give an impression of whether it
> occurs more frequently in one distribution than another, because after
> playing for 5 minutes on each, I only have a handful of instances
> total.  Any comparison would no be statistically significant, but it
> does not seem to be a large problem.  Of course that might just be my
> hardware.
>
> 2) If I click in one window and then back in source window, Focus is
> changed to the source window but the cursor position is still where it
> was when I was last in that window.  Once focus has been shifted to
> that window, cursor move properly when I click on text.  This is a
> "feature" that I see all the time on Macs.  When I have two browser
> windows open I click on a button in one, it has no effect unless that
> window already has the focus.  This is sometimes annoying for me in
> that I don't want to have to click twice to get something to happen.
> Other times I am happy that the button I just happen to click on while
> trying to bring a window to the front didn't actually register the
> click.
>
> 3) I haven't been able to get the scrollbar problem to occur, but
> again if it is an intermittent problem, perhaps I just haven't tried
> long enough.
>
> 4) The reason that the new Enthought distribution has a "Configure
> IDLE" menu option is that they threw out the IDLE.app.  Instead they
> provide a simple shell script, ".command" which then runs   "/Library/
> Frameworks/Python.framework/Versions/Current/bin/idle" in a console
> window.  So the configure problem is in IDLE.app, not idle.
>
> Later, more from Jim Mueller:
> The patch works.
> In macosxSupport.py, if you change the line
>    if tkversion >= '8.4.14':
> to
>    if map(int, tkversion.split('.')) >= (8, 4, 14):
> then you get an IDLE->Preferences menu, which contains all the  
> configuration stuff.

Of course this works, I wouldn't have closed the bugreport unless I  
knew the issue was fixed by my change (unlike whoever introduced the  
bug in the first place, the if statement was introduced somewhere  
during the development of Python 2.6 and never did what it is supposed  
to do).  I hadn't noticed before because I don't actually use IDLE  
myself (or Tkinter for that matter)
>
>
> I haven't checked the 2.5.4 version of MacPython, but since this
> change only went into the repository on Friday.  It might not be in  
> the
> bundle.

The fix shouldn't be necessary for 2.5.4, unless someone helpfully  
backported the bug to the 2.5.x branch.


BTW. W.r.t to Mac isssue: some of the issues mentioned above might be  
related to Tcl/Tk problems, which would mean there's no easy fix for  
them.  I'd really appreciate if someone who actually know's Tcl/Tk and/ 
or Tkinter could look at these problems, I know just enough of Tkinter  
to make obvious bugfixes and not enough to actually investigate these  
problems.

Ronald
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2224 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/idle-dev/attachments/20090126/fd97d2d0/attachment.bin>

From clockworksaint at gmail.com  Mon Jan 26 13:21:11 2009
From: clockworksaint at gmail.com (Weeble)
Date: Mon, 26 Jan 2009 12:21:11 +0000
Subject: [Idle-dev] Improving behaviour when moving across and deleting words
Message-ID: <13e3f9930901260421we1a413do645f5d543e94e23f@mail.gmail.com>

Often I find that IDLE just isn't doing what I expect when I hold down
Control and either press Left or Right to move the cursor
word-by-word, or press Delete or BackSpace to delete a word adjacent
to the cursor. I've also observed that it behaves differently under
Windows and Linux.

Here are some examples. I'll use ^ to denote the cursor position:

spam = [^
    1,
    2,
    3]

Press Control+Delete. Result:

spam = [^2,
    3]

Expected:

spam = [^1,
    2,
    3]

Here's another:

eggs^ = ((1,2,3),(2))

Press Control+Delete. Result:

eggs2,3),(2))

Expected:

eggs^ ((1,2,3),(2))

I think the problem is that I expect it to delete to the end of the
current token or to the end of the current block of whitespace, when
instead it deletes everything up to the next letter or digit, then
that entire "word", *then* everything up to the *next* letter or
digit. Control+BackSpace, Control+Left and Control+Right have similar
issues to varying degrees. I've noticed that Control+Left and
Control+Right on Windows will (more or less) move backwards and
forwards between the beginning of each "word", but on Linux
Control+Left moves backwards to the beginning of a word, and
Control+Right moves forwards to the end of a word, meaning that they
stop in different places when moving backwards from when moving
forwards. As far as I can tell, the discrepancy is a deliberate
"feature" of Tk. For example, see this excerpt from text.tcl:

# ::tk::TextNextWord --
# Returns the index of the next word position after a given position in the
# text.  The next word is platform dependent and may be either the next
# end-of-word position or the next start-of-word position after the next
# end-of-word position.
#
# Arguments:
# w -		The text window in which the cursor is to move.
# start -	Position at which to start search.

if {$tcl_platform(platform) eq "windows"}  {
    proc ::tk::TextNextWord {w start} {
	TextNextPos $w [TextNextPos $w $start tcl_endOfWord] \
		tcl_startOfNextWord
    }
} else {
    proc ::tk::TextNextWord {w start} {
	TextNextPos $w $start tcl_endOfWord
    }
}

Do we really want this platform-dependent distinction in IDLE? I
suspect that all these behaviours make more sense for a general text
editor/word processor than they do for a source code editor.

I would be happy to work up some patches to change the behaviour, but
I don't think there's a lot of point until some agreement can be
reached on what the behaviour should be. Perhaps my expectations are
way off and this behaviour actually feels natural to some.

I also had a look at providing this behaviour in an extension, but I
found a few problems:
    * An extension can provide events for skip-word-left and
skip-word-right and bind them by default to Control-Left and
Control-Right in the configuration file, because there are no default
bindings for those keys. But it can't do anything for Control-Delete
or Control-BackSpace because IDLE already has bindings for them.
    * It doesn't seem possible in the UI to unbind an action. You have
to bind it to obscure keys instead. This makes it quite tricky even to
manually bind Control-Delete or Control-BackSpace to my new actions.
    * An extension doesn't seem particularly useful anyway, because
users would still have to poke around in their Python directory and
edit at least one file to install it.

Note that this is all with Tk 8.5. It's possible some things have
changed since Tk 8.4.

From rt8396 at gmail.com  Tue Jan 27 00:53:55 2009
From: rt8396 at gmail.com (Mr. T)
Date: Mon, 26 Jan 2009 17:53:55 -0600
Subject: [Idle-dev] IDLE 3000 (script included)
Message-ID: <ef018e0b0901261553o4dc1597k167e03067e6e290c@mail.gmail.com>

Proposal:
OK, so the python language has officially moved into the next level. I look
at IDLE and think, hmm great IDE but it could really use a spit shining. So
here is a very simple script showing my ideas to improve IDLE.
Reason for change:
The text widget and the prompt(>>>) should be separated. Trying to write a
conditional in the interactive IDLE is a real pain. Not to mention that when
you copy code from Interactive  IDLE to the IDLE editor window the indention
is eight spaces instead four and you've got that prompt(>>>) stuck in there.
I have a solution for the problem though.

I hope you are using fixed-width font

Lst|<----- Text Widget ---->|
   |                        |
>>>|if this:                |
...|    if that:            |
...|        ...             |
...|    elif that:          |
...|        ...             |
...|    else:               |
...|        ...             |
>>>|                        |
>>>|x = 10                  |
>>>|                        |


Basically you have a Listbox on the left for the prompt and a Text on the
right. Disable the Listbox highlight and key press events and now we have a
very friendly interactive IDLE! No more prompt hijacking your snippets, and
no more eigtht space indention! Hip-Hip-Hooray!


from Tkinter import *

class CMD(Toplevel):
    def __init__(self, master, glo, loc):
        Toplevel.__init__(self, master)
        self.glo = glo
        self.loc = loc
        self.master = master
        self.startidx = '1.0'
        self.transient(master)
        self.lift(master)
        self.title('IDLE 3000')

        self.listbox = Listbox(self, width=3, relief=FLAT, font=('Courier
New',12), takefocus=0)
        self.listbox.pack(fill=Y, side=LEFT)
        self.listbox.insert(0, '>>>')

        self.text = Text(self, relief=FLAT, spacing3=1, wrap=NONE,
font=('Courier New',12))
        self.text.pack(fill=BOTH, side=LEFT, expand=1)
        self.text.config(width=50, height=10)
        self.text.focus_set()

        self.listbox.bind("<KeyPress>"          , lambda e: "break")
        self.listbox.bind("<Button-1>"          , lambda e: "break")
        self.listbox.bind("<B1-Motion>"         , lambda e: "break")
        self.listbox.bind("<ButtonRelease-1>"   , lambda e: "break")
        self.listbox.bind("<B2-Motion>"         , lambda e: "break")

        self.text.bind('<Next>'         , lambda e: "break")#pageup
        self.text.bind('<Prior>'        , lambda e: "break")#pagedown
        self.text.bind('<Delete>'       , lambda e: "break")
        self.text.bind('<Control-Home>' , lambda e: "break")
        self.text.bind('<Control-End>'  , lambda e: "break")
        self.text.bind("<B2-Motion>"    , lambda e: "break")
        self.text.bind('<Button-2>'     , lambda e: "break")
        self.text.bind("<MouseWheel>"   , lambda e: "break")

        self.text.bind("<Up>"       , self.onUp)
        self.text.bind("<Down>"     , self.onDown)
        self.text.bind("<Tab>"      , self.onTab)
        self.text.bind("<Return>"   , self.onReturn)
        self.text.bind("<BackSpace>", self.onBackSpace)

    def on_quit(self):
        self.grab_release()
        if self.master:
            self.master.focus_set()
        self.destroy()

    def onTab(self, event=None):
        curline, cursor = self.text.index(INSERT).split('.')[0]+'.0',
self.text.index(INSERT)
        self.text.insert(INSERT, '    ')
        return "break"

    def onDown(self, event):
        i = self.text.index(INSERT+'+1l') #;print 'New index: ', i
        self.text.mark_set(INSERT, i)
        self.text.see(i)
        self.listbox.see(int(i.split('.')[0])-1)
        return "break"

    def onUp(self, event):
        i = self.text.index(INSERT+'-1l') #;print 'New index: ', i
        self.text.mark_set(INSERT, i)
        self.text.see(i)
        self.listbox.see(int(i.split('.')[0])-1)
        return "break"

    def fix_index(self, chars):
        self.text.insert(END, '\n')
        self.text.mark_set(INSERT, END)
        self.text.see(INSERT)
        self.listbox.insert(END, chars)
        self.listbox.see(self.listbox.size())

    def onBackSpace(self, event=None):
        if self.text.compare(self.text.index(INSERT), '!=', self.startidx):
            self.text.delete(self.text.index(INSERT+'-1c'))
        return "break"

    def onReturn(self, event=None):
        curline, cursor = self.text.index(INSERT).split('.')[0]+'.0',
self.text.index(INSERT)
        text = self.text.get(self.startidx, END).strip()
        if self.text.compare(curline, '<', self.startidx):#'Out Of Zone'
            self.text.mark_set(INSERT, END+'-1c')
            self.text.see(INSERT)
            self.listbox.see(END)
        elif '.0' in cursor: #nothing typed on this line, try to exec
command
            cmd = text.rstrip('\n')
            try:
                exec(cmd, self.glo, self.loc)
            except:
                self.master.bell()
                print '%s\n%s\n%s' %(sys.exc_traceback, sys.exc_type,
sys.exc_value)
            finally:
                self.fix_index('>>>')
                self.startidx = self.text.index(INSERT)

        elif text != '':#something typed
            self.fix_index('...')
        else: #insert newline
            self.fix_index('>>>')
        return "break"


if __name__ == '__main__':
    print 'main'
    root = Tk()
    cmd = CMD(root, globals(), locals())
    root.mainloop()

Issue #2:
When you press MMB and there is a highlighted selection in the text it gets
pasted over and over again @ the insertion cursor. This can be aggravating,
and turn a clean script into a bowl of "Cheerios" breakfast cereal in no
time.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/idle-dev/attachments/20090126/d6e4fcbb/attachment-0001.htm>

From rt8396 at gmail.com  Tue Jan 27 18:26:07 2009
From: rt8396 at gmail.com (Mr. T)
Date: Tue, 27 Jan 2009 11:26:07 -0600
Subject: [Idle-dev] IDLE 3000_a2 (fixed non-fatal error in script)
Message-ID: <ef018e0b0901270926y473d3d38tde7c883612a02a30@mail.gmail.com>

See revised code highlighted in yellow!

Proposal:
OK, so the python language has officially moved into the next level. I look
at IDLE and think, hmm great IDE but it could really use a spit shining. So
here is a very simple script showing my ideas to improve IDLE.
Reason for change:
The text widget and the prompt(>>>) should be separated. Trying to write a
conditional in the interactive IDLE is a real pain. Not to mention that when
you copy code from Interactive  IDLE to the IDLE editor window the indention
is eight spaces instead four and you've got that prompt(>>>) stuck in there.
I have a solution for the problem though.

I hope you are using fixed-width font

Lst|<----- Text Widget ---->|
   |                        |
>>>|if this:                |
...|    if that:            |
...|        ...             |
...|    elif that:          |
...|        ...             |
...|    else:               |
...|        ...             |
>>>|                        |
>>>|x = 10                  |
>>>|                        |


Basically you have a Listbox on the left for the prompt and a Text on the
right. Disable the Listbox highlight and key press events and now we have a
very friendly interactive IDLE! No more prompt hijacking your snippets, and
no more eigtht space indention! Hip-Hip-Hooray!

from Tkinter import *
import tkMessageBox as MB

class CMD(Toplevel):
    def __init__(self, master):
        Toplevel.__init__(self, master)
        self.master = master
        self.startidx = '1.0'
        self.backidx = '1.0'
        self.title('IDLE 3000')

        self.listbox = Listbox(self, width=3, relief=FLAT, font=('Courier
New',12), takefocus=0)
        self.listbox.pack(fill=Y, side=LEFT)
        self.listbox.insert(0, '>>>')

        self.text = Text(self, relief=FLAT, spacing3=1, wrap=NONE,
font=('Courier New',12))
        self.text.pack(fill=BOTH, side=LEFT, expand=1)
        self.text.config(width=50, height=20)
        self.text.focus_set()

        self.listbox.bind("<KeyPress>"          , lambda e: "break")
        self.listbox.bind("<Button-1>"          , lambda e: "break")
        self.listbox.bind("<B1-Motion>"         , lambda e: "break")
        self.listbox.bind("<ButtonRelease-1>"   , lambda e: "break")
        self.listbox.bind("<B2-Motion>"         , lambda e: "break")
        self.listbox.bind("<MouseWheel>"        , lambda e: "break")

        self.text.bind('<Next>'         , lambda e: "break")#pageup
        self.text.bind('<Prior>'        , lambda e: "break")#pagedown
        self.text.bind('<Delete>'       , lambda e: "break")
        self.text.bind('<Control-Home>' , lambda e: "break")
        self.text.bind('<Control-End>'  , lambda e: "break")
        self.text.bind("<B2-Motion>"    , lambda e: "break")
        self.text.bind('<Button-2>'     , lambda e: "break")
        self.text.bind("<MouseWheel>"   , lambda e: "break")

        self.text.bind("<Up>"       , self.onUp)
        self.text.bind("<Down>"     , self.onDown)
        self.text.bind("<Tab>"      , self.onTab)
        self.text.bind("<Return>"   , self.onReturn)
        self.text.bind("<BackSpace>", self.onBackSpace)

        self.protocol("WM_DELETE_WINDOW", self.onQuit)
        self.lift(master)
        self.master.withdraw()

    def fix_index(self, chars):
        self.backidx = '%d.0' %(int(self.backidx.split('.')[0])+1)
        self.text.insert(END, '\n')
        self.text.mark_set(INSERT, END)
        self.text.see(INSERT)
        self.listbox.insert(END, chars)
        self.listbox.see(self.listbox.size())

    def onQuit(self):
        self.grab_release()
        self.master.destroy()

    def onTab(self, event=None):
        curline, cursor = self.text.index(INSERT).split('.')[0]+'.0',
self.text.index(INSERT)
        self.text.insert(INSERT, '    ')
        return "break"

    def onDown(self, event):
        i = self.text.index(INSERT+'+1l') #;print 'New index: ', i
        self.text.mark_set(INSERT, i)
        self.text.see(i)
        self.listbox.see(int(i.split('.')[0])-1)
        return "break"

    def onUp(self, event=None):
        i = self.text.index(INSERT+'-1l') #;print 'New index: ', i
        self.text.mark_set(INSERT, i)
        self.text.see(i)
        self.listbox.see(int(i.split('.')[0])-1)
        return "break"

    def onBackSpace(self, event=None):
        if self.text.compare(self.text.index(INSERT), '!=', self.backidx):
            self.text.delete(self.text.index(INSERT+'-1c'))
        return "break"

    def onReturn(self, event=None):
        curline, cursor = self.text.index(INSERT).split('.')[0]+'.0',
self.text.index(INSERT)
        text = self.text.get(self.startidx, END).strip()
        if self.text.compare(curline, '<', self.startidx):#'Out Of Zone'
            self.text.mark_set(INSERT, END+'-1c')
            self.text.see(INSERT)
            self.listbox.see(END)
        elif '.0' in cursor: #nothing typed on this line, try to exec
command
            cmd = text.rstrip('\n')
            try:
                exec(cmd)
            except:
                self.master.bell()
                print '%s\n%s\n%s' %(sys.exc_traceback, sys.exc_type,
sys.exc_value)
            finally:
                self.fix_index('>>>')
                self.startidx = self.text.index(INSERT)
        elif text != '':#something typed
            self.fix_index('...')
        else: #insert newline
            self.fix_index('>>>')
        return "break"


if __name__ == '__main__':
    print 'main'
    root = Tk()

    MB.showinfo('IDLE 3000 Introduction','''
This Demo shows how i think the standard IDLE should behave.
You will notice the prompt is outside of the text widget. This
keeps the prompt from hijacking your code snippits when you
copy-paste to the main editor window. This also keeps all indention
at the Python recommended four spaces.

Please note this demo is to only show the layout, it does not include
syntax highlight, auto-tab, auto-dedent, or any other feature. This is
not even the correct way to write a good editor. My only intention is to
show a more user friendly layout

have fun :)
''')
    cmd = CMD(root)
    root.mainloop()



Issue #2:
When you press MMB and there is a highlighted selection in the text it gets
pasted over and over again @ the insertion cursor. This can be aggravating,
and turn a clean script into a bowl of "Cheerios" breakfast cereal in no
time.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/idle-dev/attachments/20090127/06df9ad6/attachment-0001.htm>