From noreply@sourceforge.net Sat Mar 1 02:18:22 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Fri, 28 Feb 2003 18:18:22 -0800 Subject: [Idle-dev] [ idlefork-Bugs-661324 ] Does not play well with Tkinter when on-quit handler invoked Message-ID: Bugs item #661324, was opened at 2003-01-02 21:58 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=661324&group_id=9579 Category: None Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Chui Tey (teyc) Assigned to: Nobody/Anonymous (nobody) Summary: Does not play well with Tkinter when on-quit handler invoked Initial Comment: The following program: import Tkinter import sys root = Tkinter.Tk() console = Tkinter.Button(root, text='Done', command=root.quit) console.pack() root.mainloop() locks up the running program if "Done" is pressed. The program stops locking when the Shell window is closed. I observed this behaviour on Windows 2000, running ASPN Python 2.2. ---------------------------------------------------------------------- Comment By: David Harris (edcdave) Date: 2003-03-01 02:18 Message: Logged In: YES user_id=72287 The same behavior occurs when the command is "sys.exit". Since the 'Close Window' widget works correctly, I looked at the Tkinter source to learn what was different. But I didn't go very far before I encountered some example code in Tkinter.py which uses tk.destroy as the command (where tk=Tk()). Once I change to "destroy", the given code exits correctly, erasing the window. Windows XP. IdleFork 0.92a. Python 2.2.2 ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-01-03 17:51 Message: Logged In: YES user_id=149084 Confirmed on IDLEfork/Linux. Code can be Run again, though, don't need to close shell. Is that true for Windows? Same program crashes Python IDLE on second button press, something about a Tk callback error. Probably some kind of self abuse issue? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=661324&group_id=9579 From noreply@sourceforge.net Sun Mar 2 03:40:10 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 01 Mar 2003 19:40:10 -0800 Subject: [Idle-dev] [ idlefork-Bugs-695861 ] Unnecessary blank line triggered by continuation in Shell Message-ID: Bugs item #695861, was opened at 2003-03-02 03:40 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=695861&group_id=9579 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: David Harris (edcdave) Assigned to: Nobody/Anonymous (nobody) Summary: Unnecessary blank line triggered by continuation in Shell Initial Comment: Windows XP, IDLEfork 0.9a2, Python 2.2.2 The following interactive session generates an unexpected blank line: >>> word = 'letters' >>> for c in word: print c, # continuation line, pressed Enter l e t t e r s >>> 'h' in word # unexpected blank line 0 >>> 'e' in word 1 >>> IDLE 0.8 does not generate the unexpected blank line. The behavior seems to be triggered by a prior need for a continuation line. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=695861&group_id=9579 From noreply@sourceforge.net Sun Mar 2 03:42:42 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 01 Mar 2003 19:42:42 -0800 Subject: [Idle-dev] [ idlefork-Bugs-693333 ] Misleading message for 'exit' Message-ID: Bugs item #693333, was opened at 2003-02-26 01:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=693333&group_id=9579 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: David Harris (edcdave) Assigned to: Nobody/Anonymous (nobody) Summary: Misleading message for 'exit' Initial Comment: If you attempt to use 'exit' as a command, IdleFork responds: 'Use Ctrl-Z plus Return to exit.'. This is apparently a holdover from Idle. Ctrl-Z is now setup by default to perform 'Undo' Either exit should be treated as an unrecognized command or it should respond 'Use Ctrl-Q to exit' ---------------------------------------------------------------------- >Comment By: David Harris (edcdave) Date: 2003-03-02 03:42 Message: Logged In: YES user_id=72287 The same message is display for 'quit' as well. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=693333&group_id=9579 From noreply@sourceforge.net Sun Mar 2 12:51:38 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 02 Mar 2003 04:51:38 -0800 Subject: [Idle-dev] [ idlefork-Bugs-695861 ] Unnecessary blank line triggered by continuation in Shell Message-ID: Bugs item #695861, was opened at 2003-03-01 22:40 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=695861&group_id=9579 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: David Harris (edcdave) Assigned to: Nobody/Anonymous (nobody) Summary: Unnecessary blank line triggered by continuation in Shell Initial Comment: Windows XP, IDLEfork 0.9a2, Python 2.2.2 The following interactive session generates an unexpected blank line: >>> word = 'letters' >>> for c in word: print c, # continuation line, pressed Enter l e t t e r s >>> 'h' in word # unexpected blank line 0 >>> 'e' in word 1 >>> IDLE 0.8 does not generate the unexpected blank line. The behavior seems to be triggered by a prior need for a continuation line. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-03-02 07:51 Message: Logged In: YES user_id=6380 It's not a continuation line. More likely it's that the subprocess where your code runs has an unterminated output line for which both it and IDLE's stdout provide an extra newline at some later point. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=695861&group_id=9579 From noreply@sourceforge.net Sun Mar 2 17:52:16 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 02 Mar 2003 09:52:16 -0800 Subject: [Idle-dev] [ idlefork-Bugs-695861 ] Unnecessary blank line triggered by continuation in Shell Message-ID: Bugs item #695861, was opened at 2003-03-02 03:40 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=695861&group_id=9579 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: David Harris (edcdave) Assigned to: Nobody/Anonymous (nobody) Summary: Unnecessary blank line triggered by continuation in Shell Initial Comment: Windows XP, IDLEfork 0.9a2, Python 2.2.2 The following interactive session generates an unexpected blank line: >>> word = 'letters' >>> for c in word: print c, # continuation line, pressed Enter l e t t e r s >>> 'h' in word # unexpected blank line 0 >>> 'e' in word 1 >>> IDLE 0.8 does not generate the unexpected blank line. The behavior seems to be triggered by a prior need for a continuation line. ---------------------------------------------------------------------- >Comment By: David Harris (edcdave) Date: 2003-03-02 17:52 Message: Logged In: YES user_id=72287 I think I understand. The comma is contributing to the behavior, but I'm not sure that's the whole story. For example, >>> print "test", test >>> print "test" test >>> print "test" test The second output has a leading space (induced by the first command?). But why didn't I get a blank line like the original example? My apologies for submitting what seems to be a superficial bug. I'm very new to Python, but I have 20 years experience in C and others. When I saw the on-again/off-again behavior of the blank line, I imagined a situation where a variable was not reset (which could have a wider impact than the display). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-03-02 12:51 Message: Logged In: YES user_id=6380 It's not a continuation line. More likely it's that the subprocess where your code runs has an unterminated output line for which both it and IDLE's stdout provide an extra newline at some later point. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=695861&group_id=9579 From dpharris76@msn.com Sun Mar 2 20:24:13 2003 From: dpharris76@msn.com (David Harris) Date: Sun, 2 Mar 2003 14:24:13 -0600 Subject: [Idle-dev] IDLEfork 0.9a2 - Duplicate items in sys.path Message-ID: This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C2E0C7.65FE6600 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable When main() expands the current directory element (" ") of sys.path, a = duplicate item will be added to sys.path if the current directory is a = member of sys.path. For example, if my current directory is = "C:\\Python22\\Scripts", I end up with two instances for this directory. = That is: ['C:\\Python22\\Scripts', 'C:\\Python22\\Scripts', = 'C:\\PYTHON22\\DLLs', 'C:\\PYTHON22\\lib', 'C:\\PYTHON22\\lib\\lib-tk', = 'C:\\PYTHON22', 'C:\\PYTHON22\\lib\\site-packages'] The duplicate(s) can be eliminated by changing: # process sys.argv and sys.path: for i in range(len(sys.path)): sys.path[i] =3D os.path.abspath(sys.path[i]) to: # process sys.argv and sys.path: temppath =3D [] for i in range(len(sys.path)): pathitem =3D os.path.abspath(sys.path[i]) if pathitem not in temppath: temppath.append(pathitem) sys.path =3D temppath but is this really desirable (and does it even matter)? The new code = will also drop duplicates which were present in PYTHONPATH. Is that good = or bad? Thanks, Dave Harris ------=_NextPart_000_0005_01C2E0C7.65FE6600 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
When main() expands the current = directory element=20 (" ") of sys.path, a duplicate item will be added to sys.path if the = current=20 directory is a member of sys.path. For example, if my current directory = is=20 "C:\\Python22\\Scripts", I end up with two instances for this directory. = That=20 is: ['C:\\Python22\\Scripts', 'C:\\Python22\\Scripts',=20 'C:\\PYTHON22\\DLLs', 'C:\\PYTHON22\\lib', 'C:\\PYTHON22\\lib\\lib-tk',=20 'C:\\PYTHON22', 'C:\\PYTHON22\\lib\\site-packages']
The duplicate(s) can be eliminated by=20 changing:
 
    # process sys.argv = and=20 sys.path:
    for i in=20 range(len(sys.path)):
        = sys.path[i]=20 =3D os.path.abspath(sys.path[i])
to:
 
    # process sys.argv = and=20 sys.path:
    temppath =3D []
    = for i in=20 range(len(sys.path)):
        = pathitem =3D=20 os.path.abspath(sys.path[i])
        if = pathitem not in temppath:
       =20     temppath.append(pathitem)
    = sys.path =3D=20 temppath
but is this really desirable (and does = it even=20 matter)? The new code will also drop duplicates which were = present in=20 PYTHONPATH. Is that good or bad?
 
Thanks,
Dave Harris
------=_NextPart_000_0005_01C2E0C7.65FE6600-- From dpharris76@msn.com Sun Mar 2 21:09:02 2003 From: dpharris76@msn.com (David Harris) Date: Sun, 2 Mar 2003 15:09:02 -0600 Subject: [Idle-dev] OT: Apology for appearance of last post Message-ID: Sorry for the previous hideous posting. MS Outlook Express makes me look like more of a moron than I actually am. Does anyone know of a way to beat that program into submission? I think I found one control (plain text vs. rich text). Maybe this message will be more presentable. If it's not possible, can anyone recommend a Windows XP mail package which can politely converse with this mail list? Again, my sincere apology, Dave Harris From kbk@shore.net Sun Mar 2 22:50:19 2003 From: kbk@shore.net (Kurt B. Kaiser) Date: Sun, 02 Mar 2003 17:50:19 -0500 Subject: [Idle-dev] OT: Apology for appearance of last post In-Reply-To: ("David Harris"'s message of "Sun, 2 Mar 2003 15:09:02 -0600") References: Message-ID: "David Harris" writes: > Does anyone know of a way to beat that program into submission? I > think I found one control (plain text vs. rich text). Maybe this > message will be more presentable. If it's not possible, can anyone > recommend a Windows XP mail package which can politely converse with > this mail list? Not a problem. It would be nice if you had proper line endings at 72 or so. I don't know how to get Outlook to do that because IMHO it's not really safe to use. My personal recommendation is to install Emacs and use Gnus. Doing that has many benefits. But Gnus has a steep learning curve. www.gnus.org I've made a lot of posts in the past with Mozilla/Netscape, and it can be set up (with a bit of fiddling and testing) to give proper line endings with 72 char per line. The biggest problem is re-formatting when quoting, which Gnus can handle easily. -- HTH, KBK From kbk@shore.net Sun Mar 2 23:30:20 2003 From: kbk@shore.net (Kurt B. Kaiser) Date: Sun, 02 Mar 2003 18:30:20 -0500 Subject: [Idle-dev] IDLEfork 0.9a2 - Duplicate items in sys.path In-Reply-To: ("David Harris"'s message of "Sun, 2 Mar 2003 14:24:13 -0600") References: Message-ID: "David Harris" writes: > When main() expands the current directory element (" ") of sys.path, > a duplicate item will be added to sys.path if the current directory > is a member of sys.path. For example, if my current directory is > "C:\\Python22\\Scripts", I end up with two instances for this > directory. That is: ['C:\\Python22\\Scripts', > 'C:\\Python22\\Scripts', 'C:\\PYTHON22\\DLLs', 'C:\\PYTHON22\\lib', > 'C:\\PYTHON22\\lib\\lib-tk', 'C:\\PYTHON22', > 'C:\\PYTHON22\\lib\\site-packages'] > > The duplicate(s) can be eliminated by changing: > > # process sys.argv and sys.path: > for i in range(len(sys.path)): > sys.path[i] = os.path.abspath(sys.path[i]) > > to: > > # process sys.argv and sys.path: > temppath = [] > for i in range(len(sys.path)): > pathitem = os.path.abspath(sys.path[i]) > if pathitem not in temppath: > temppath.append(pathitem) > sys.path = temppath > > but is this really desirable (and does it even matter)? The new code > will also drop duplicates which were present in PYTHONPATH. Is that > good or bad? The situation is a little complicated; it's a Python issue, seems to me. Windows ======= When Python is started with a script: sys.path[0] is the directory of the script being run [1] current working directory unless we're just starting Python interactively w/o a script: sys.path[0] is '', which expands to a duplicate. [1] is the current working directory So the path is already duplicated by the time it get to IDLE. There is code a little further down in PyShell from the place you noted which avoids further duplication. You can play with this by running a script in a subdirectory of Scripts and doing things like ..\..\python ..\printpath.py where printpath.py prints out the sys.path etc. Linux ===== When Python is started with a script or from an executable file (i.e. first line is #!/usr/bin/env python) sys.path[0] is the location of the executable file. When IDLEfork is installed, sys.path[0] becomes /usr/bin. This kind of behaviour may be useful for introspection. When Python is started interactively, sys.path[0] is '' IDLEfork adds the cwd if it's not already in sys.path. There's really no great harm in the duplication. My vote on pruning the path is +0. Maybe GvR has an opinion. -- KBK From noreply@sourceforge.net Mon Mar 3 01:18:36 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 02 Mar 2003 17:18:36 -0800 Subject: [Idle-dev] [ idlefork-Bugs-695861 ] Unnecessary blank line triggered by continuation in Shell Message-ID: Bugs item #695861, was opened at 2003-03-01 22:40 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=695861&group_id=9579 Category: None Group: None Status: Open >Resolution: Accepted >Priority: 3 Submitted By: David Harris (edcdave) Assigned to: Nobody/Anonymous (nobody) Summary: Unnecessary blank line triggered by continuation in Shell Initial Comment: Windows XP, IDLEfork 0.9a2, Python 2.2.2 The following interactive session generates an unexpected blank line: >>> word = 'letters' >>> for c in word: print c, # continuation line, pressed Enter l e t t e r s >>> 'h' in word # unexpected blank line 0 >>> 'e' in word 1 >>> IDLE 0.8 does not generate the unexpected blank line. The behavior seems to be triggered by a prior need for a continuation line. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2003-03-02 20:18 Message: Logged In: YES user_id=149084 Somewhat simplified: Python 2.2.2 (#1, Mar 2 2003, 00:38:54) [GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2 Type "copyright", "credits" or "license" for more information. IDLEfork 0.9a2 >>> print 1, 1 >>> 1 1 >>> 1 1 When the code for '1' is executed the subprocess is sending a request to print \n before its request to print '1'. It seems that the whitespace character is being held off somehow and replaced with a newline if the following statement isn't a "print". Curious it doesn't happen with IDLE0.8. This is a little hard to debug and not too important compared to some other things so I'm lowering the priority and putting it on the back burner. If you want to dig in and supply a patch I'll bet you learn a bit about Python before you're done :-) ---------------------------------------------------------------------- Comment By: David Harris (edcdave) Date: 2003-03-02 12:52 Message: Logged In: YES user_id=72287 I think I understand. The comma is contributing to the behavior, but I'm not sure that's the whole story. For example, >>> print "test", test >>> print "test" test >>> print "test" test The second output has a leading space (induced by the first command?). But why didn't I get a blank line like the original example? My apologies for submitting what seems to be a superficial bug. I'm very new to Python, but I have 20 years experience in C and others. When I saw the on-again/off-again behavior of the blank line, I imagined a situation where a variable was not reset (which could have a wider impact than the display). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-03-02 07:51 Message: Logged In: YES user_id=6380 It's not a continuation line. More likely it's that the subprocess where your code runs has an unterminated output line for which both it and IDLE's stdout provide an extra newline at some later point. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=695861&group_id=9579 From noreply@sourceforge.net Mon Mar 3 13:16:13 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 03 Mar 2003 05:16:13 -0800 Subject: [Idle-dev] [ idlefork-Bugs-695861 ] Unnecessary blank line triggered by continuation in Shell Message-ID: Bugs item #695861, was opened at 2003-03-01 22:40 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=695861&group_id=9579 Category: None Group: None Status: Open Resolution: Accepted Priority: 3 Submitted By: David Harris (edcdave) >Assigned to: Kurt B. Kaiser (kbk) Summary: Unnecessary blank line triggered by continuation in Shell Initial Comment: Windows XP, IDLEfork 0.9a2, Python 2.2.2 The following interactive session generates an unexpected blank line: >>> word = 'letters' >>> for c in word: print c, # continuation line, pressed Enter l e t t e r s >>> 'h' in word # unexpected blank line 0 >>> 'e' in word 1 >>> IDLE 0.8 does not generate the unexpected blank line. The behavior seems to be triggered by a prior need for a continuation line. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-03-03 08:16 Message: Logged In: YES user_id=6380 You need a way to force a call to Py_FlushLine() after the subprocess is finished. Unfortunately I don't know how to force that without writing C code. In Python 2.3, we could move the call in sys_displayhook() up so that it is executed even when o equals None; then you could call sys.displayhook(None) at the end. Would that work? I'd be willing to add that to Python 2.3b1. (I hope IDLEfork will be ready for inclusion in Python by then too.) ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-03-02 20:18 Message: Logged In: YES user_id=149084 Somewhat simplified: Python 2.2.2 (#1, Mar 2 2003, 00:38:54) [GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2 Type "copyright", "credits" or "license" for more information. IDLEfork 0.9a2 >>> print 1, 1 >>> 1 1 >>> 1 1 When the code for '1' is executed the subprocess is sending a request to print \n before its request to print '1'. It seems that the whitespace character is being held off somehow and replaced with a newline if the following statement isn't a "print". Curious it doesn't happen with IDLE0.8. This is a little hard to debug and not too important compared to some other things so I'm lowering the priority and putting it on the back burner. If you want to dig in and supply a patch I'll bet you learn a bit about Python before you're done :-) ---------------------------------------------------------------------- Comment By: David Harris (edcdave) Date: 2003-03-02 12:52 Message: Logged In: YES user_id=72287 I think I understand. The comma is contributing to the behavior, but I'm not sure that's the whole story. For example, >>> print "test", test >>> print "test" test >>> print "test" test The second output has a leading space (induced by the first command?). But why didn't I get a blank line like the original example? My apologies for submitting what seems to be a superficial bug. I'm very new to Python, but I have 20 years experience in C and others. When I saw the on-again/off-again behavior of the blank line, I imagined a situation where a variable was not reset (which could have a wider impact than the display). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-03-02 07:51 Message: Logged In: YES user_id=6380 It's not a continuation line. More likely it's that the subprocess where your code runs has an unterminated output line for which both it and IDLE's stdout provide an extra newline at some later point. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=695861&group_id=9579 From noreply@sourceforge.net Mon Mar 3 18:45:04 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 03 Mar 2003 10:45:04 -0800 Subject: [Idle-dev] [ idlefork-Bugs-695861 ] Unnecessary blank line in Shell Message-ID: Bugs item #695861, was opened at 2003-03-01 22:40 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=695861&group_id=9579 Category: None Group: None Status: Open Resolution: Accepted Priority: 3 Submitted By: David Harris (edcdave) Assigned to: Kurt B. Kaiser (kbk) >Summary: Unnecessary blank line in Shell Initial Comment: Windows XP, IDLEfork 0.9a2, Python 2.2.2 The following interactive session generates an unexpected blank line: >>> word = 'letters' >>> for c in word: print c, # continuation line, pressed Enter l e t t e r s >>> 'h' in word # unexpected blank line 0 >>> 'e' in word 1 >>> IDLE 0.8 does not generate the unexpected blank line. The behavior seems to be triggered by a prior need for a continuation line. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2003-03-03 13:45 Message: Logged In: YES user_id=149084 It might not solve the problem? The problem seems to be associated with the proxying of stdout in run.py. If I redirect the subprocess' stdout to __stderr__ the whitespace char is output immediately. i.e. print 1, results in a x31 x20. However, when redirected via rpc.py's MethodProxy the space following the first print 1, is held off and output before a subsequent x31. Putting a trace print in MethodProxy.__call__(), here's a trace of the second "print 1,": #C MainThread asynccall:7: exec runcode (", line 1>,) {} #C MainThread putmessage:7: #S MainThread pollresponse:7:myseq:None #S MainThread pollresponse:7:localcall:call: #S MainThread localcall: ('call', ('exec', 'runcode', (", line 1>,), {})) ** MethodProxy.__call__(oid, name, args): stdout write (' ',) #S MainThread remotecall:asynccall: stdout write #S MainThread asynccall:8: stdout write (' ',) {} #S MainThread putmessage:8: #S MainThread asyncreturn:8:call getresponse(): #S MainThread _getresponse:myseq: 8 #C MainThread pollresponse:8:myseq:7 #C MainThread pollresponse:8:localcall:call: #C MainThread localcall: ('call', ('stdout', 'write', (' ',), {})) #C MainThread pollresponse:8:localcall:response:('OK', None) #C MainThread putmessage:8: #S MainThread pollresponse:8:myseq:8 #S MainThread asyncreturn:8:response: ('OK', None) ** MethodProxy.__call__(oid, name, args): stdout write ('1',) #S MainThread remotecall:asynccall: stdout write #S MainThread asynccall:10: stdout write ('1',) {} #S MainThread putmessage:10: #S MainThread asyncreturn:10:call getresponse(): #S MainThread _getresponse:myseq: 10 #C MainThread pollresponse:10:myseq:7 #C MainThread pollresponse:10:localcall:call: #C MainThread localcall: ('call', ('stdout', 'write', ('1',), {})) #C MainThread pollresponse:10:localcall:response:('OK', None) #C MainThread putmessage:10: #S MainThread pollresponse:10:myseq:10 #S MainThread asyncreturn:10:response: ('OK', None) #S MainThread pollresponse:7:localcall:response:('OK', None) #S MainThread putmessage:7: #C MainThread pollresponse:7:myseq:7 ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-03-03 08:16 Message: Logged In: YES user_id=6380 You need a way to force a call to Py_FlushLine() after the subprocess is finished. Unfortunately I don't know how to force that without writing C code. In Python 2.3, we could move the call in sys_displayhook() up so that it is executed even when o equals None; then you could call sys.displayhook(None) at the end. Would that work? I'd be willing to add that to Python 2.3b1. (I hope IDLEfork will be ready for inclusion in Python by then too.) ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-03-02 20:18 Message: Logged In: YES user_id=149084 Somewhat simplified: Python 2.2.2 (#1, Mar 2 2003, 00:38:54) [GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2 Type "copyright", "credits" or "license" for more information. IDLEfork 0.9a2 >>> print 1, 1 >>> 1 1 >>> 1 1 When the code for '1' is executed the subprocess is sending a request to print \n before its request to print '1'. It seems that the whitespace character is being held off somehow and replaced with a newline if the following statement isn't a "print". Curious it doesn't happen with IDLE0.8. This is a little hard to debug and not too important compared to some other things so I'm lowering the priority and putting it on the back burner. If you want to dig in and supply a patch I'll bet you learn a bit about Python before you're done :-) ---------------------------------------------------------------------- Comment By: David Harris (edcdave) Date: 2003-03-02 12:52 Message: Logged In: YES user_id=72287 I think I understand. The comma is contributing to the behavior, but I'm not sure that's the whole story. For example, >>> print "test", test >>> print "test" test >>> print "test" test The second output has a leading space (induced by the first command?). But why didn't I get a blank line like the original example? My apologies for submitting what seems to be a superficial bug. I'm very new to Python, but I have 20 years experience in C and others. When I saw the on-again/off-again behavior of the blank line, I imagined a situation where a variable was not reset (which could have a wider impact than the display). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-03-02 07:51 Message: Logged In: YES user_id=6380 It's not a continuation line. More likely it's that the subprocess where your code runs has an unterminated output line for which both it and IDLE's stdout provide an extra newline at some later point. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=695861&group_id=9579 From noreply@sourceforge.net Mon Mar 3 18:56:41 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 03 Mar 2003 10:56:41 -0800 Subject: [Idle-dev] [ idlefork-Bugs-695861 ] Unnecessary blank line in Shell Message-ID: Bugs item #695861, was opened at 2003-03-01 22:40 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=695861&group_id=9579 Category: None Group: None Status: Open Resolution: Accepted Priority: 3 Submitted By: David Harris (edcdave) Assigned to: Kurt B. Kaiser (kbk) Summary: Unnecessary blank line in Shell Initial Comment: Windows XP, IDLEfork 0.9a2, Python 2.2.2 The following interactive session generates an unexpected blank line: >>> word = 'letters' >>> for c in word: print c, # continuation line, pressed Enter l e t t e r s >>> 'h' in word # unexpected blank line 0 >>> 'e' in word 1 >>> IDLE 0.8 does not generate the unexpected blank line. The behavior seems to be triggered by a prior need for a continuation line. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2003-03-03 13:56 Message: Logged In: YES user_id=6380 I don't follow the trace, but your first experiment might not have been right. "print 1," does not produce a space or newline until something else is done to the same file. If you see it appear immediately, that must be because something else *is* done to the file. Since you sent it to sys.stderr, I think that what happens is that something is done just before printing the next prompt. However, I was wrong about needing to write C code for this. softspace is a normal attribute on files, and you can implement the effect of Py_FlushLine() as follows: if sys.stdout.softspace: sys.stdout.softspace = 0 sys.stdout.write("\n") (well, you may have to expect an AttributeError and then skip the whole thing.) ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-03-03 13:45 Message: Logged In: YES user_id=149084 It might not solve the problem? The problem seems to be associated with the proxying of stdout in run.py. If I redirect the subprocess' stdout to __stderr__ the whitespace char is output immediately. i.e. print 1, results in a x31 x20. However, when redirected via rpc.py's MethodProxy the space following the first print 1, is held off and output before a subsequent x31. Putting a trace print in MethodProxy.__call__(), here's a trace of the second "print 1,": #C MainThread asynccall:7: exec runcode (", line 1>,) {} #C MainThread putmessage:7: #S MainThread pollresponse:7:myseq:None #S MainThread pollresponse:7:localcall:call: #S MainThread localcall: ('call', ('exec', 'runcode', (", line 1>,), {})) ** MethodProxy.__call__(oid, name, args): stdout write (' ',) #S MainThread remotecall:asynccall: stdout write #S MainThread asynccall:8: stdout write (' ',) {} #S MainThread putmessage:8: #S MainThread asyncreturn:8:call getresponse(): #S MainThread _getresponse:myseq: 8 #C MainThread pollresponse:8:myseq:7 #C MainThread pollresponse:8:localcall:call: #C MainThread localcall: ('call', ('stdout', 'write', (' ',), {})) #C MainThread pollresponse:8:localcall:response:('OK', None) #C MainThread putmessage:8: #S MainThread pollresponse:8:myseq:8 #S MainThread asyncreturn:8:response: ('OK', None) ** MethodProxy.__call__(oid, name, args): stdout write ('1',) #S MainThread remotecall:asynccall: stdout write #S MainThread asynccall:10: stdout write ('1',) {} #S MainThread putmessage:10: #S MainThread asyncreturn:10:call getresponse(): #S MainThread _getresponse:myseq: 10 #C MainThread pollresponse:10:myseq:7 #C MainThread pollresponse:10:localcall:call: #C MainThread localcall: ('call', ('stdout', 'write', ('1',), {})) #C MainThread pollresponse:10:localcall:response:('OK', None) #C MainThread putmessage:10: #S MainThread pollresponse:10:myseq:10 #S MainThread asyncreturn:10:response: ('OK', None) #S MainThread pollresponse:7:localcall:response:('OK', None) #S MainThread putmessage:7: #C MainThread pollresponse:7:myseq:7 ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-03-03 08:16 Message: Logged In: YES user_id=6380 You need a way to force a call to Py_FlushLine() after the subprocess is finished. Unfortunately I don't know how to force that without writing C code. In Python 2.3, we could move the call in sys_displayhook() up so that it is executed even when o equals None; then you could call sys.displayhook(None) at the end. Would that work? I'd be willing to add that to Python 2.3b1. (I hope IDLEfork will be ready for inclusion in Python by then too.) ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-03-02 20:18 Message: Logged In: YES user_id=149084 Somewhat simplified: Python 2.2.2 (#1, Mar 2 2003, 00:38:54) [GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2 Type "copyright", "credits" or "license" for more information. IDLEfork 0.9a2 >>> print 1, 1 >>> 1 1 >>> 1 1 When the code for '1' is executed the subprocess is sending a request to print \n before its request to print '1'. It seems that the whitespace character is being held off somehow and replaced with a newline if the following statement isn't a "print". Curious it doesn't happen with IDLE0.8. This is a little hard to debug and not too important compared to some other things so I'm lowering the priority and putting it on the back burner. If you want to dig in and supply a patch I'll bet you learn a bit about Python before you're done :-) ---------------------------------------------------------------------- Comment By: David Harris (edcdave) Date: 2003-03-02 12:52 Message: Logged In: YES user_id=72287 I think I understand. The comma is contributing to the behavior, but I'm not sure that's the whole story. For example, >>> print "test", test >>> print "test" test >>> print "test" test The second output has a leading space (induced by the first command?). But why didn't I get a blank line like the original example? My apologies for submitting what seems to be a superficial bug. I'm very new to Python, but I have 20 years experience in C and others. When I saw the on-again/off-again behavior of the blank line, I imagined a situation where a variable was not reset (which could have a wider impact than the display). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-03-02 07:51 Message: Logged In: YES user_id=6380 It's not a continuation line. More likely it's that the subprocess where your code runs has an unterminated output line for which both it and IDLE's stdout provide an extra newline at some later point. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=695861&group_id=9579 From kbk@users.sourceforge.net Mon Mar 3 20:06:53 2003 From: kbk@users.sourceforge.net (Kurt B. Kaiser) Date: Mon, 03 Mar 2003 12:06:53 -0800 Subject: [Idle-dev] CVS: idle run.py,1.11,1.12 Message-ID: Update of /cvsroot/idlefork/idle In directory sc8-pr-cvs1:/tmp/cvs-serv25199 Modified Files: run.py Log Message: SF 695861 Eliminate extra blank line in shell output. Caused by stdout not being flushed upon completion of subprocess' Executive.runcode() when user code ends by outputting an unterminated line, e.g. print "test", Index: run.py =================================================================== RCS file: /cvsroot/idlefork/idle/run.py,v retrieving revision 1.11 retrieving revision 1.12 diff -C2 -r1.11 -r1.12 *** run.py 27 Feb 2003 23:04:17 -0000 1.11 --- run.py 3 Mar 2003 20:06:48 -0000 1.12 *************** *** 74,82 **** exec code in self.locals except: efile = sys.stderr typ, val, tb = info = sys.exc_info() sys.last_type, sys.last_value, sys.last_traceback = info tbe = traceback.extract_tb(tb) ! print >>efile, '\nTraceback (most recent call last):' exclude = ("run.py", "rpc.py", "RemoteDebugger.py", "bdb.py") self.cleanup_traceback(tbe, exclude) --- 74,83 ---- exec code in self.locals except: + self.flush_stdout() efile = sys.stderr typ, val, tb = info = sys.exc_info() sys.last_type, sys.last_value, sys.last_traceback = info tbe = traceback.extract_tb(tb) ! print >>efile, 'Traceback (most recent call last):' exclude = ("run.py", "rpc.py", "RemoteDebugger.py", "bdb.py") self.cleanup_traceback(tbe, exclude) *************** *** 85,88 **** --- 86,98 ---- for line in lines: print>>efile, line, + self.flush_stdout() + + def flush_stdout(self): + try: + if sys.stdout.softspace: + sys.stdout.softspace = 0 + sys.stdout.write("\n") + except AttributeError: + pass def cleanup_traceback(self, tb, exclude): From noreply@sourceforge.net Mon Mar 3 20:19:15 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 03 Mar 2003 12:19:15 -0800 Subject: [Idle-dev] [ idlefork-Bugs-695861 ] Unnecessary blank line in Shell Message-ID: Bugs item #695861, was opened at 2003-03-01 22:40 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=695861&group_id=9579 Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 3 Submitted By: David Harris (edcdave) Assigned to: Kurt B. Kaiser (kbk) Summary: Unnecessary blank line in Shell Initial Comment: Windows XP, IDLEfork 0.9a2, Python 2.2.2 The following interactive session generates an unexpected blank line: >>> word = 'letters' >>> for c in word: print c, # continuation line, pressed Enter l e t t e r s >>> 'h' in word # unexpected blank line 0 >>> 'e' in word 1 >>> IDLE 0.8 does not generate the unexpected blank line. The behavior seems to be triggered by a prior need for a continuation line. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2003-03-03 15:19 Message: Logged In: YES user_id=149084 Yes, __stderr__ was being flushed by the trace. Thanks for the solution! run.py Rev 1.12 ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-03-03 13:56 Message: Logged In: YES user_id=6380 I don't follow the trace, but your first experiment might not have been right. "print 1," does not produce a space or newline until something else is done to the same file. If you see it appear immediately, that must be because something else *is* done to the file. Since you sent it to sys.stderr, I think that what happens is that something is done just before printing the next prompt. However, I was wrong about needing to write C code for this. softspace is a normal attribute on files, and you can implement the effect of Py_FlushLine() as follows: if sys.stdout.softspace: sys.stdout.softspace = 0 sys.stdout.write("\n") (well, you may have to expect an AttributeError and then skip the whole thing.) ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-03-03 13:45 Message: Logged In: YES user_id=149084 It might not solve the problem? The problem seems to be associated with the proxying of stdout in run.py. If I redirect the subprocess' stdout to __stderr__ the whitespace char is output immediately. i.e. print 1, results in a x31 x20. However, when redirected via rpc.py's MethodProxy the space following the first print 1, is held off and output before a subsequent x31. Putting a trace print in MethodProxy.__call__(), here's a trace of the second "print 1,": #C MainThread asynccall:7: exec runcode (", line 1>,) {} #C MainThread putmessage:7: #S MainThread pollresponse:7:myseq:None #S MainThread pollresponse:7:localcall:call: #S MainThread localcall: ('call', ('exec', 'runcode', (", line 1>,), {})) ** MethodProxy.__call__(oid, name, args): stdout write (' ',) #S MainThread remotecall:asynccall: stdout write #S MainThread asynccall:8: stdout write (' ',) {} #S MainThread putmessage:8: #S MainThread asyncreturn:8:call getresponse(): #S MainThread _getresponse:myseq: 8 #C MainThread pollresponse:8:myseq:7 #C MainThread pollresponse:8:localcall:call: #C MainThread localcall: ('call', ('stdout', 'write', (' ',), {})) #C MainThread pollresponse:8:localcall:response:('OK', None) #C MainThread putmessage:8: #S MainThread pollresponse:8:myseq:8 #S MainThread asyncreturn:8:response: ('OK', None) ** MethodProxy.__call__(oid, name, args): stdout write ('1',) #S MainThread remotecall:asynccall: stdout write #S MainThread asynccall:10: stdout write ('1',) {} #S MainThread putmessage:10: #S MainThread asyncreturn:10:call getresponse(): #S MainThread _getresponse:myseq: 10 #C MainThread pollresponse:10:myseq:7 #C MainThread pollresponse:10:localcall:call: #C MainThread localcall: ('call', ('stdout', 'write', ('1',), {})) #C MainThread pollresponse:10:localcall:response:('OK', None) #C MainThread putmessage:10: #S MainThread pollresponse:10:myseq:10 #S MainThread asyncreturn:10:response: ('OK', None) #S MainThread pollresponse:7:localcall:response:('OK', None) #S MainThread putmessage:7: #C MainThread pollresponse:7:myseq:7 ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-03-03 08:16 Message: Logged In: YES user_id=6380 You need a way to force a call to Py_FlushLine() after the subprocess is finished. Unfortunately I don't know how to force that without writing C code. In Python 2.3, we could move the call in sys_displayhook() up so that it is executed even when o equals None; then you could call sys.displayhook(None) at the end. Would that work? I'd be willing to add that to Python 2.3b1. (I hope IDLEfork will be ready for inclusion in Python by then too.) ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-03-02 20:18 Message: Logged In: YES user_id=149084 Somewhat simplified: Python 2.2.2 (#1, Mar 2 2003, 00:38:54) [GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2 Type "copyright", "credits" or "license" for more information. IDLEfork 0.9a2 >>> print 1, 1 >>> 1 1 >>> 1 1 When the code for '1' is executed the subprocess is sending a request to print \n before its request to print '1'. It seems that the whitespace character is being held off somehow and replaced with a newline if the following statement isn't a "print". Curious it doesn't happen with IDLE0.8. This is a little hard to debug and not too important compared to some other things so I'm lowering the priority and putting it on the back burner. If you want to dig in and supply a patch I'll bet you learn a bit about Python before you're done :-) ---------------------------------------------------------------------- Comment By: David Harris (edcdave) Date: 2003-03-02 12:52 Message: Logged In: YES user_id=72287 I think I understand. The comma is contributing to the behavior, but I'm not sure that's the whole story. For example, >>> print "test", test >>> print "test" test >>> print "test" test The second output has a leading space (induced by the first command?). But why didn't I get a blank line like the original example? My apologies for submitting what seems to be a superficial bug. I'm very new to Python, but I have 20 years experience in C and others. When I saw the on-again/off-again behavior of the blank line, I imagined a situation where a variable was not reset (which could have a wider impact than the display). ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-03-02 07:51 Message: Logged In: YES user_id=6380 It's not a continuation line. More likely it's that the subprocess where your code runs has an unterminated output line for which both it and IDLE's stdout provide an extra newline at some later point. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=695861&group_id=9579 From noreply@sourceforge.net Tue Mar 4 03:25:33 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 03 Mar 2003 19:25:33 -0800 Subject: [Idle-dev] [ idlefork-Bugs-689543 ] File/SaveAs Raises Tkinter Callback Error Message-ID: Bugs item #689543, was opened at 2003-02-19 14:39 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=689543&group_id=9579 Category: None Group: None Status: Open >Resolution: Works For Me Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Kurt B. Kaiser (kbk) >Summary: File/SaveAs Raises Tkinter Callback Error Initial Comment: I installed Python 2.3a1. I start IDLE by 'python idle.py' and the shell window is open in the background. When I want to save an idle session I do not get a file. In the shell window I get this error message: ------------------------------------------------------- Exception in Tkinter callback Traceback (most recent call last): File "/usr/local/lib/python2.3/lib-tk/Tkinter.py", line 1306, in __call__ return apply(self.func, args) File "/usr/local/lib/python2.3/site-packages/idlelib/IOBinding.py", line 273, in save self.save_as(event) File "/usr/local/lib/python2.3/site-packages/idlelib/IOBinding.py", line 282, in save_as filename = self.asksavefile() File "/usr/local/lib/python2.3/site-packages/idlelib/IOBinding.py", line 441, in asksavefile return self.savedialog.show(initialdir=dir, initialfile=base) File "/usr/local/lib/python2.3/lib-tk/tkCommonDialog.py", line 54, in show s = self._fixresult(w, s) File "/usr/local/lib/python2.3/lib-tk/tkFileDialog.py", line 58, in _fixresult path, file = os.path.split(result) File "/usr/local/lib/python2.3/posixpath.py", line 65, in split i = p.rfind('/') + 1 AttributeError: '_tkinter.Tcl_Obj' object has no attribute 'rfind' ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2003-03-03 22:25 Message: Logged In: YES user_id=149084 You appear to be using IDLEfork installed from the tarfile. I can't reproduce this problem on Linux using Python2.2.2, Python2.3a0(14Dec), or Python2.3a2. What version of Tcl/Tk do you have? I did find a different problem where IDLEfork was trying to save the breaks from the shell (there are none), so I fixed that. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=689543&group_id=9579 From kbk@users.sourceforge.net Tue Mar 4 04:03:50 2003 From: kbk@users.sourceforge.net (Kurt B. Kaiser) Date: Mon, 03 Mar 2003 20:03:50 -0800 Subject: [Idle-dev] CVS: idle PyShell.py,1.56,1.57 Message-ID: Update of /cvsroot/idlefork/idle In directory sc8-pr-cvs1:/tmp/cvs-serv5716 Modified Files: PyShell.py Log Message: SF 693333 Modify subprocess to print a reasonable message upon receiving a 'quit' or 'exit' Index: PyShell.py =================================================================== RCS file: /cvsroot/idlefork/idle/PyShell.py,v retrieving revision 1.56 retrieving revision 1.57 diff -C2 -r1.56 -r1.57 *** PyShell.py 17 Feb 2003 18:57:16 -0000 1.56 --- PyShell.py 4 Mar 2003 04:03:45 -0000 1.57 *************** *** 419,422 **** --- 419,425 ---- _sys.path = %s del _sys + _msg = 'Use File/Exit or your end-of-file key to quit IDLE' + __builtins__.quit = __builtins__.exit = _msg + del _msg \n""" % `sys.path`) From noreply@sourceforge.net Tue Mar 4 04:14:28 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 03 Mar 2003 20:14:28 -0800 Subject: [Idle-dev] [ idlefork-Bugs-693333 ] Misleading message for 'exit' Message-ID: Bugs item #693333, was opened at 2003-02-25 20:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=693333&group_id=9579 Category: None Group: None Status: Open >Resolution: Fixed Priority: 5 Submitted By: David Harris (edcdave) >Assigned to: Kurt B. Kaiser (kbk) Summary: Misleading message for 'exit' Initial Comment: If you attempt to use 'exit' as a command, IdleFork responds: 'Use Ctrl-Z plus Return to exit.'. This is apparently a holdover from Idle. Ctrl-Z is now setup by default to perform 'Undo' Either exit should be treated as an unrecognized command or it should respond 'Use Ctrl-Q to exit' ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2003-03-03 23:14 Message: Logged In: YES user_id=149084 PyShell 1.57 ---------------------------------------------------------------------- Comment By: David Harris (edcdave) Date: 2003-03-01 22:42 Message: Logged In: YES user_id=72287 The same message is display for 'quit' as well. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=693333&group_id=9579 From noreply@sourceforge.net Tue Mar 4 04:15:21 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 03 Mar 2003 20:15:21 -0800 Subject: [Idle-dev] [ idlefork-Bugs-693333 ] Misleading message for 'exit' Message-ID: Bugs item #693333, was opened at 2003-02-25 20:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=693333&group_id=9579 Category: None Group: None >Status: Closed Resolution: Fixed Priority: 5 Submitted By: David Harris (edcdave) Assigned to: Kurt B. Kaiser (kbk) Summary: Misleading message for 'exit' Initial Comment: If you attempt to use 'exit' as a command, IdleFork responds: 'Use Ctrl-Z plus Return to exit.'. This is apparently a holdover from Idle. Ctrl-Z is now setup by default to perform 'Undo' Either exit should be treated as an unrecognized command or it should respond 'Use Ctrl-Q to exit' ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-03-03 23:14 Message: Logged In: YES user_id=149084 PyShell 1.57 ---------------------------------------------------------------------- Comment By: David Harris (edcdave) Date: 2003-03-01 22:42 Message: Logged In: YES user_id=72287 The same message is display for 'quit' as well. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=693333&group_id=9579 From noreply@sourceforge.net Tue Mar 4 04:31:37 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 03 Mar 2003 20:31:37 -0800 Subject: [Idle-dev] [ idlefork-Bugs-691827 ] saving required to run script Message-ID: Bugs item #691827, was opened at 2003-02-23 15:21 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=691827&group_id=9579 Category: None Group: None >Status: Closed >Resolution: Duplicate Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Kurt B. Kaiser (kbk) Summary: saving required to run script Initial Comment: (I couldn't enter this as a feature request; it seems to be broken.) Whenever one tries to run a one-shot program or test, he/she still must save it as a file. It would be much better if the user had the option to save, or turn off the prompt in Preferences. Dr. Scheme is a good example where this makes things much faster. I suppose this guards against code loss, but not all situations really need this protection, and it could be saved in a backup file anyway. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2003-03-03 23:31 Message: Logged In: YES user_id=149084 Duplicate of RFE 661318 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=691827&group_id=9579 From kbk@users.sourceforge.net Tue Mar 4 04:42:06 2003 From: kbk@users.sourceforge.net (Kurt B. Kaiser) Date: Mon, 03 Mar 2003 20:42:06 -0800 Subject: [Idle-dev] CVS: idle IOBinding.py,1.12,1.13 Message-ID: Update of /cvsroot/idlefork/idle In directory sc8-pr-cvs1:/tmp/cvs-serv19845 Modified Files: IOBinding.py Log Message: Attempting to save the shell raised an error related to saving breakpoints, which are not implemented in the shell Index: IOBinding.py =================================================================== RCS file: /cvsroot/idlefork/idle/IOBinding.py,v retrieving revision 1.12 retrieving revision 1.13 diff -C2 -r1.12 -r1.13 *** IOBinding.py 31 Dec 2002 15:59:14 -0000 1.12 --- IOBinding.py 4 Mar 2003 04:42:04 -0000 1.13 *************** *** 275,279 **** if self.writefile(self.filename): self.set_saved(1) ! self.editwin.store_file_breaks() self.text.focus_set() return "break" --- 275,282 ---- if self.writefile(self.filename): self.set_saved(1) ! try: ! self.editwin.store_file_breaks() ! except AttributeError: # may be a PyShell ! pass self.text.focus_set() return "break" *************** *** 285,289 **** self.set_filename(filename) self.set_saved(1) ! self.editwin.store_file_breaks() self.text.focus_set() self.updaterecentfileslist(filename) --- 288,295 ---- self.set_filename(filename) self.set_saved(1) ! try: ! self.editwin.store_file_breaks() ! except AttributeError: ! pass self.text.focus_set() self.updaterecentfileslist(filename) From webmaster@pferdemarkt.ws Thu Mar 6 14:04:49 2003 From: webmaster@pferdemarkt.ws (webmaster@pferdemarkt.ws) Date: Thu, 6 Mar 2003 06:04:49 -0800 Subject: [Idle-dev] Pferdemarkt.ws informiert! Newsletter 03/2003 http://www.pferdemarkt.ws Message-ID: <200303061404.GAA22753@eagle.he.net> http://www.pferdemarkt.ws Wir sind in 2003 erfolgreich in des neue \"Pferdejahr 2003 gestartet. Für den schnellen Erfolg unseres Marktes möchten wir uns bei Ihnen bedanken. Heute am 06.03.2003 sind wir gut 2 Monate Online! Täglich wächst unsere Datenbank um 30 Neue Angebote. Stellen auch Sie als Privatperson Ihre zu verkaufenden Pferde direkt und vollkommen kostenlos ins Internet. Zur besseren Sichtbarmachung Ihrer Angebote können Sie bis zu ein Bild zu Ihrer Pferdeanzeige kostenlos einstellen! Wollen Sie direkt auf die erste Seite, dann können wir Ihnen unser Bonussystem empfehlen. klicken Sie hier: http://www.pferdemarkt.ws/bestellung.html Ihr http://Pferdemarkt.ws Team Klicken Sie hier um sich direkt einzuloggen http://www.Pferdemarkt.ws Kostenlos Anbieten, Kostenlos Suchen! Direkt von Privat zu Privat! Haben Sie noch Fragen mailto: webmaster@pferdemarkt.ws From noreply@sourceforge.net Sun Mar 9 15:58:04 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 09 Mar 2003 07:58:04 -0800 Subject: [Idle-dev] [ idlefork-Bugs-700391 ] Deletion of user .cfg file inhibits launch from WinXP icon Message-ID: Bugs item #700391, was opened at 2003-03-09 15:58 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=700391&group_id=9579 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: David Harris (edcdave) Assigned to: Nobody/Anonymous (nobody) Summary: Deletion of user .cfg file inhibits launch from WinXP icon Initial Comment: In a malevolent universe, someone might... Create a highlighting theme 'splunge' using 'Configure IDLE' Delete .idlerc\congif-highlight.cfg This leads to a situation which is detected and handled by IdleConf.GetThemeDict(), but results in a puzzling behavior. >From Desktop icon (Target -> C:\Python22 \Scripts\idlefork.pyw): Noticeable pause, but no Shell window >From console window (current directory -> C:\Python22 \Scripts): python idlefork.pyw Multiple warning messages appear in the console window (such as): Warning: configHandler.py - IdleConf.GetThemeDict - problem retrieving theme element 'error-background' from theme 'splunge'. returning default value: '#000000' Then the Shell window is displayed Something is inhibiting the Shell window. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=700391&group_id=9579 From kbk@users.sourceforge.net Mon Mar 10 20:41:12 2003 From: kbk@users.sourceforge.net (Kurt B. Kaiser) Date: Mon, 10 Mar 2003 12:41:12 -0800 Subject: [Idle-dev] CVS: idle interruptmodule.c,NONE,1.1 setup.py,1.13,1.14 Message-ID: Update of /cvsroot/idlefork/idle In directory sc8-pr-cvs1:/tmp/cvs-serv20028 Modified Files: setup.py Added Files: interruptmodule.c Log Message: A interruptmodule.c M setup.py Implements an interrupt extension module which allows a subthread to raise an interrupt in the main thread. --- NEW FILE: interruptmodule.c --- /*********************************************************************** * interruptmodule.c * * Python extension implementing the interrupt module. * **********************************************************************/ #include "Python.h" #ifndef PyDoc_STR #define PyDoc_VAR(name) static char name[] #define PyDoc_STR(str) str #define PyDoc_STRVAR(name,str) PyDoc_VAR(name) = PyDoc_STR(str) #endif /* module documentation */ PyDoc_STRVAR(module_doc, "Provide a way to interrupt the main thread from a subthread.\n\n\ In threaded Python code the KeyboardInterrupt is always directed to\n\ the thread which raised it. This extension provides a method,\n\ interrupt_main, which a subthread can use to raise a KeyboardInterrupt\n\ in the main thread."); /* module functions */ static PyObject * setinterrupt(PyObject * self, PyObject * args) { PyErr_SetInterrupt(); Py_INCREF(Py_None); return Py_None; } /* registration table */ static struct PyMethodDef methods[] = { {"interrupt_main", setinterrupt, METH_VARARGS, PyDoc_STR("Interrupt the main thread")}, {NULL, NULL} }; /* module initialization */ void initinterrupt(void) { (void) Py_InitModule3("interrupt", methods, module_doc); } Index: setup.py =================================================================== RCS file: /cvsroot/idlefork/idle/setup.py,v retrieving revision 1.13 retrieving revision 1.14 diff -C2 -r1.13 -r1.14 *** setup.py 21 Jan 2003 04:42:50 -0000 1.13 --- setup.py 10 Mar 2003 20:41:07 -0000 1.14 *************** *** 1,4 **** import os, glob, sys ! from distutils.core import setup from distutils.command.build_py import build_py from distutils.command.install_lib import install_lib --- 1,4 ---- import os, glob, sys ! from distutils.core import setup, Extension from distutils.command.build_py import build_py from distutils.command.install_lib import install_lib *************** *** 112,115 **** --- 112,116 ---- package_dir = {pkgname: pkg_dir}, packages = [pkgname], + ext_modules = [Extension("interrupt", ["interruptmodule.c"])], scripts = [os.path.join(pkg_dir, idle_name)] ) From kbk@users.sourceforge.net Mon Mar 10 20:42:35 2003 From: kbk@users.sourceforge.net (Kurt B. Kaiser) Date: Mon, 10 Mar 2003 12:42:35 -0800 Subject: [Idle-dev] CVS: idle PyShell.py,1.57,1.58 rpc.py,1.17,1.18 Message-ID: Update of /cvsroot/idlefork/idle In directory sc8-pr-cvs1:/tmp/cvs-serv21021 Modified Files: PyShell.py rpc.py Log Message: M PyShell.py M rpc.py Improve exception handing if peer process has terminated. Index: PyShell.py =================================================================== RCS file: /cvsroot/idlefork/idle/PyShell.py,v retrieving revision 1.57 retrieving revision 1.58 diff -C2 -r1.57 -r1.58 *** PyShell.py 4 Mar 2003 04:03:45 -0000 1.57 --- PyShell.py 10 Mar 2003 20:42:22 -0000 1.58 *************** *** 401,405 **** except ImportError: SIGINT = 2 ! os.kill(self.rpcpid, SIGINT) def __request_interrupt(self): --- 401,408 ---- except ImportError: SIGINT = 2 ! try: ! os.kill(self.rpcpid, SIGINT) ! except OSError: # subprocess may have already exited ! pass def __request_interrupt(self): Index: rpc.py =================================================================== RCS file: /cvsroot/idlefork/idle/rpc.py,v retrieving revision 1.17 retrieving revision 1.18 diff -C2 -r1.17 -r1.18 *** rpc.py 27 Feb 2003 23:04:15 -0000 1.17 --- rpc.py 10 Mar 2003 20:42:24 -0000 1.18 *************** *** 167,170 **** --- 167,172 ---- except SystemExit: raise + except socket.error: + pass except: self.debug("localcall:EXCEPTION") From noreply@sourceforge.net Tue Mar 11 06:12:14 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 10 Mar 2003 22:12:14 -0800 Subject: [Idle-dev] [ idlefork-Bugs-701352 ] Cannot backspace through ">>> " in doc comment Message-ID: Bugs item #701352, was opened at 2003-03-11 06:12 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=701352&group_id=9579 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: David Harris (edcdave) Assigned to: Nobody/Anonymous (nobody) Summary: Cannot backspace through ">>> " in doc comment Initial Comment: IDLEfork 0.9a2, Python 2.2.2, Windows XP I was documenting another case of Tkinter freeze by adding a doc comment in an Editor window when I found that the backspace key will not erase a line beginning with >>> followed by a space. That is, """ Pressed F5 to run Example window appeared Clicked button >>> appeared in Shell window ... more comments >>> ...more comments """ When I attempted use backspace to delete the ">>> " line, the cursor refused to move leftward. Pressing Home and hitting the Delete key 4 times works fine. Two things to think about: 1) The syntax highlighting indicates the cursor is in the middle of a comment. 2) This occurred in an Edit window, not a Shell window FWIW, this defect is hardly worth mentioning. But, if IDLE is a tool used by beginners, these odd behaviors undermine confidence. When I encountered this defect, there was a period of 10 seconds when I thought IDLEfork locked up - the backspace key just wasn't working. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=701352&group_id=9579 From kbk@users.sourceforge.net Tue Mar 11 22:55:59 2003 From: kbk@users.sourceforge.net (Kurt B. Kaiser) Date: Tue, 11 Mar 2003 14:55:59 -0800 Subject: [Idle-dev] CVS: idle rpc.py,1.18,1.19 run.py,1.12,1.13 Message-ID: Update of /cvsroot/idlefork/idle In directory sc8-pr-cvs1:/tmp/cvs-serv21237 Modified Files: rpc.py run.py Log Message: M rpc.py M run.py 1. Clarify that rpc.SocketIO._getresponse() currently blocks on socket. 2. Improve exception handling in subprocess when GUI terminates abruptly. Index: rpc.py =================================================================== RCS file: /cvsroot/idlefork/idle/rpc.py,v retrieving revision 1.18 retrieving revision 1.19 diff -C2 -r1.18 -r1.19 *** rpc.py 10 Mar 2003 20:42:24 -0000 1.18 --- rpc.py 11 Mar 2003 22:55:54 -0000 1.19 *************** *** 241,247 **** if threading.currentThread() is self.mainthread: # Main thread: does all reading of requests or responses ! # Loop here until there is message traffic on the socket while 1: ! response = self.pollresponse(myseq, None) if response is not None: return response --- 241,247 ---- if threading.currentThread() is self.mainthread: # Main thread: does all reading of requests or responses ! # Loop here, blocking each time until socket is ready. while 1: ! response = self.pollresponse(myseq, wait=None) if response is not None: return response *************** *** 347,351 **** if message is None: # socket not ready return None ! wait = 0.0 seq, resq = message self.debug("pollresponse:%d:myseq:%s" % (seq, myseq)) --- 347,351 ---- if message is None: # socket not ready return None ! #wait = 0.0 # poll on subsequent passes instead of blocking seq, resq = message self.debug("pollresponse:%d:myseq:%s" % (seq, myseq)) Index: run.py =================================================================== RCS file: /cvsroot/idlefork/idle/run.py,v retrieving revision 1.12 retrieving revision 1.13 diff -C2 -r1.12 -r1.13 *** run.py 3 Mar 2003 20:06:48 -0000 1.12 --- run.py 11 Mar 2003 22:55:56 -0000 1.13 *************** *** 93,97 **** sys.stdout.softspace = 0 sys.stdout.write("\n") ! except AttributeError: pass --- 93,97 ---- sys.stdout.softspace = 0 sys.stdout.write("\n") ! except (AttributeError, EOFError): pass From kbk@users.sourceforge.net Wed Mar 12 20:52:03 2003 From: kbk@users.sourceforge.net (Kurt B. Kaiser) Date: Wed, 12 Mar 2003 12:52:03 -0800 Subject: [Idle-dev] CVS: idle rpc.py,1.19,1.20 NEWS.txt,1.11,1.12 Message-ID: Update of /cvsroot/idlefork/idle In directory sc8-pr-cvs1:/tmp/cvs-serv13524 Modified Files: rpc.py NEWS.txt Log Message: Move setting of ioready 'wait' earlier in call chain, to rpc.SocketIO.main() and asyncreturn(). Improve comment. Index: rpc.py =================================================================== RCS file: /cvsroot/idlefork/idle/rpc.py,v retrieving revision 1.19 retrieving revision 1.20 diff -C2 -r1.19 -r1.20 *** rpc.py 11 Mar 2003 22:55:54 -0000 1.19 --- rpc.py 12 Mar 2003 20:51:59 -0000 1.20 *************** *** 193,197 **** def asyncreturn(self, seq): self.debug("asyncreturn:%d:call getresponse(): " % seq) ! response = self.getresponse(seq) self.debug(("asyncreturn:%d:response: " % seq), response) return self.decoderesponse(response) --- 193,197 ---- def asyncreturn(self, seq): self.debug("asyncreturn:%d:call getresponse(): " % seq) ! response = self.getresponse(seq, wait=None) self.debug(("asyncreturn:%d:response: " % seq), response) return self.decoderesponse(response) *************** *** 212,226 **** """Listen on socket until I/O not ready or EOF ! pollpacket() will loop looking for seq number None, which never ! comes. The loop will exit when self.ioready() returns 0. """ try: ! self.getresponse(None) except EOFError: pass ! def getresponse(self, myseq): ! response = self._getresponse(myseq) if response is not None: how, what = response --- 212,226 ---- """Listen on socket until I/O not ready or EOF ! Main thread pollresponse() will loop looking for seq number None, which ! never comes, and exit on EOFError. """ try: ! self.getresponse(myseq=None, wait=None) except EOFError: pass ! def getresponse(self, myseq, wait): ! response = self._getresponse(myseq, wait) if response is not None: how, what = response *************** *** 237,241 **** return obj ! def _getresponse(self, myseq): self.debug("_getresponse:myseq:", myseq) if threading.currentThread() is self.mainthread: --- 237,241 ---- return obj ! def _getresponse(self, myseq, wait): self.debug("_getresponse:myseq:", myseq) if threading.currentThread() is self.mainthread: *************** *** 243,247 **** # Loop here, blocking each time until socket is ready. while 1: ! response = self.pollresponse(myseq, wait=None) if response is not None: return response --- 243,247 ---- # Loop here, blocking each time until socket is ready. while 1: ! response = self.pollresponse(myseq, wait) if response is not None: return response Index: NEWS.txt =================================================================== RCS file: /cvsroot/idlefork/idle/NEWS.txt,v retrieving revision 1.11 retrieving revision 1.12 diff -C2 -r1.11 -r1.12 *** NEWS.txt 17 Feb 2003 18:57:16 -0000 1.11 --- NEWS.txt 12 Mar 2003 20:52:00 -0000 1.12 *************** *** 8,11 **** --- 8,26 ---- *Release date: xx-xxx-2003* + - Implemented the 'interrupt' extension module, which allows a subthread + to raise a KeyboardInterrupt in the main thread. + + - Attempting to save the shell raised an error related to saving + breakpoints, which are not implemented in the shell + + - Provide a correct message when 'exit' or 'quit' are entered at the + IDLE command prompt SF 695861 + + - Eliminate extra blank line in shell output caused by not flushing + stdout when user code ends with an unterminated print. SF 695861 + + - Moved responsibility for exception formatting (i.e. pruning IDLE internal + calls) out of rpc.py into the client and server. + - Exit IDLE cleanly even when doing subprocess I/O *************** *** 13,16 **** --- 28,32 ---- - Calling Run will restart the subprocess even if user code is running. + SF RFE 661321 - Restart the subprocess if it terminates itself. (VPython programs do that) From noreply@sourceforge.net Sat Mar 15 23:26:41 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sat, 15 Mar 2003 15:26:41 -0800 Subject: [Idle-dev] [ idlefork-Patches-704316 ] Squeezer - an extension to turn long outputs into buttons Message-ID: Patches item #704316, was opened at 2003-03-16 01:26 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=309579&aid=704316&group_id=9579 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Noam Raphael (noamr) Assigned to: Nobody/Anonymous (nobody) Summary: Squeezer - an extension to turn long outputs into buttons Initial Comment: When this extension is active, it wraps the write method of a PyShell instance so that if a long output is to be printed, a button will be inserted into the Text widget. The output could then be previewed in an external viewer (such as less), and could be expanded back to a normal text. Also, existing outputs can be squeezed into such a button by using a command from the right-click menu. The files attached are: - the extension module - its configuration options in config-extensions.def - a small fix to configHandler.py, to disable ConfigParser's format-strings feature. This feature, which lets you specify configuration strings which relate to other configuration strings, is not used in IDLEfork currently, and doesn't let me pass my own format strings in the configuration string. I need them because the command to start the viewer should have a place for the temporary file which contains the text - for example, this is the configuration string for linux: preview-command-posix=(xterm -e less %(fn)s; rm -f %(fn)s) & Note that configuration strings are used currently for specifying the printing command, but no problem arises because they are unnamed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=309579&aid=704316&group_id=9579 From noreply@sourceforge.net Mon Mar 17 18:07:52 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 17 Mar 2003 10:07:52 -0800 Subject: [Idle-dev] [ idlefork-Bugs-661324 ] Does not play well with Tkinter when on-quit handler invoked Message-ID: Bugs item #661324, was opened at 2003-01-02 21:58 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=661324&group_id=9579 Category: None Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Chui Tey (teyc) Assigned to: Nobody/Anonymous (nobody) Summary: Does not play well with Tkinter when on-quit handler invoked Initial Comment: The following program: import Tkinter import sys root = Tkinter.Tk() console = Tkinter.Button(root, text='Done', command=root.quit) console.pack() root.mainloop() locks up the running program if "Done" is pressed. The program stops locking when the Shell window is closed. I observed this behaviour on Windows 2000, running ASPN Python 2.2. ---------------------------------------------------------------------- Comment By: David Harris (edcdave) Date: 2003-03-17 18:07 Message: Logged In: YES user_id=72287 I have tried several work-arounds and have come up with a quit technique which always works. Unfortunately, I can't figure out how to change IDLEfork to accomplish the necessary action. The problem is that quit() (a member of the Misc class) goes for the jugular and tries to kill the top-top-level widget - the Tk() window opened by IDLE. I found that walking the container chain backwards and destroying the first 'Tk' widget works, even it Tk() is not explicitly invoked by the application (that is, master=None). Here's an example: def quit(self): # where self is a Tk widget or an instance # object with a widget attribute parent = self while parent.winfo_class() != 'Tk': if parent.master == None: break; parent = parent.master else: parent.destroy() The fact that this works indicates to me that Misc quit() is ignoring the toplevel window for the application and zapping IDLE's toplevel window instead. ---------------------------------------------------------------------- Comment By: David Harris (edcdave) Date: 2003-03-01 02:18 Message: Logged In: YES user_id=72287 The same behavior occurs when the command is "sys.exit". Since the 'Close Window' widget works correctly, I looked at the Tkinter source to learn what was different. But I didn't go very far before I encountered some example code in Tkinter.py which uses tk.destroy as the command (where tk=Tk()). Once I change to "destroy", the given code exits correctly, erasing the window. Windows XP. IdleFork 0.92a. Python 2.2.2 ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-01-03 17:51 Message: Logged In: YES user_id=149084 Confirmed on IDLEfork/Linux. Code can be Run again, though, don't need to close shell. Is that true for Windows? Same program crashes Python IDLE on second button press, something about a Tk callback error. Probably some kind of self abuse issue? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=661324&group_id=9579 From noreply@sourceforge.net Thu Mar 20 12:21:50 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 20 Mar 2003 04:21:50 -0800 Subject: [Idle-dev] [ idlefork-Bugs-706860 ] sys.path does not contain source file directory Message-ID: Bugs item #706860, was opened at 2003-03-20 12:21 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=706860&group_id=9579 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Dickon Reed (dickon) Assigned to: Nobody/Anonymous (nobody) Summary: sys.path does not contain source file directory Initial Comment: With idlefork 0.8.1, when a script was run the current working directory was set to the script location, and the script location was added to sys.path. Therefore, imports of modules in the same directory as the script location worked even if the user had not made an effort to place the script location on the module path. With idlefork 0.9a2, for me it seems neither the current working directory nor sys.path get updated with the script location. Thus imports do not work for modules in the same location as the script (unless the location is in sys.path anyway). My actions were: 1. Install python 2.2.1 from python labs on Win2K in c:\python22 2. Install idlefork 0.9a2. 3. Rename C:\python22\scripts\idlefork to C:\python22\scripts\idlefork.py 4. Launch C:\python22\scripts\idlefork.py 5. Create a script using idlefork 0.9a2: import os, sys print 'cwd', os.getcwd() print 'path', sys.path 6. Save the script as C:\ 7. Run the script from within idlefork. 8. Output is: cwd C:\Python22\Scripts path ['C:\Python22\Scripts', 'C:\Python22\Scripts', 'C:\Python22\DLLs', 'C:\Python22\lib', 'C:\Python22\lib\lib-tk', 'C:\Python22', 'C:\Python22\lib\site-packages'] I'm not sure whether the CWD should be updated or not (I note idlefork 0.8.1 does, but running the script from the path on Linux doesn't). But it shouldn't it the case that one is able to import modules from the same directory as the launched script without having to worry about setting sys.path. I haven't tried this with other platforms or the CVS version. I believe this is the same problem reported on comp.lang.python here: http://groups.google.com/groups?dq=&hl=en&lr=&ie=UTF-8&oe=utf-8&threadm=3E79728C.AED36CCD%40alcyone.com&prev=/groups%3Fhl%3Den%26lr%3D%26ie%3DUTF-8%26oe%3Dutf-8%26group%3Dcomp.lang.python win2k and winxp, python labs python 2.2.1 idlefork 0.9a2 from idlefork.sf.net ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=706860&group_id=9579 From azm25m8ihnaw@att.net Thu Mar 20 17:20:06 2003 From: azm25m8ihnaw@att.net (Emerson Lund) Date: Thu, 20 Mar 03 17:20:06 GMT Subject: [Idle-dev] She Can go Message-ID: This is a multi-part message in MIME format. --_A7FC7F_E___F1EE84348F Content-Type: text/html Content-Transfer-Encoding: quoted-printable
=
3D""
 
 
3D""
 
 
 
koqvz l bldvdh e m --_A7FC7F_E___F1EE84348F-- From kbk@users.sourceforge.net Sat Mar 22 19:16:02 2003 From: kbk@users.sourceforge.net (Kurt B. Kaiser) Date: Sat, 22 Mar 2003 11:16:02 -0800 Subject: [Idle-dev] CVS: idle rpc.py,1.20,1.21 Message-ID: Update of /cvsroot/idlefork/idle In directory sc8-pr-cvs1:/tmp/cvs-serv20354 Modified Files: rpc.py Log Message: Improve error message handling. Index: rpc.py =================================================================== RCS file: /cvsroot/idlefork/idle/rpc.py,v retrieving revision 1.20 retrieving revision 1.21 diff -C2 -r1.20 -r1.21 *** rpc.py 12 Mar 2003 20:51:59 -0000 1.20 --- rpc.py 22 Mar 2003 19:15:58 -0000 1.21 *************** *** 88,98 **** def handle_error(self, request, client_address): ! """Override TCPServer method, no error message if exiting""" try: raise except SystemExit: raise ! else: ! TCPServer.handle_error(request, client_address) --- 88,116 ---- def handle_error(self, request, client_address): ! """Override TCPServer method ! ! Error message goes to __stderr__. No error message if exiting ! normally or socket raised EOF. Other exceptions not handled in ! server code will cause os._exit. ! ! """ try: raise except SystemExit: raise ! except EOFError: ! pass ! except: ! erf = 'sys.__stderr__' ! print>>erf, '-'*40 ! print>>erf, 'Unhandled server exception!' ! print>>erf, 'Thread: %s' % threading.currentThread().getName() ! print>>erf, 'Client Address: ', address ! print>>erf, 'Request: ', repr(request) ! traceback.print_exc(file=erf) ! print>>erf, '\n*** Unrecoverable, server exiting!' ! print>>erf, '-'*40 ! import os ! os._exit From neal@metaslash.com Sat Mar 22 19:40:15 2003 From: neal@metaslash.com (Neal Norwitz) Date: Sat, 22 Mar 2003 14:40:15 -0500 Subject: [Idle-dev] CVS: idle rpc.py,1.20,1.21 In-Reply-To: References: Message-ID: <20030322194015.GE25722@epoch.metaslash.com> > def handle_error(self, request, client_address): > ! """Override TCPServer method > ! > ! Error message goes to __stderr__. No error message if exiting > ! normally or socket raised EOF. Other exceptions not handled in > ! server code will cause os._exit. > ! > ! """ > try: > raise > except SystemExit: > raise > ! except EOFError: > ! pass > ! except: > ! erf = 'sys.__stderr__' > ! print>>erf, '-'*40 > ! print>>erf, 'Unhandled server exception!' > ! print>>erf, 'Thread: %s' % threading.currentThread().getName() > ! print>>erf, 'Client Address: ', address > ! print>>erf, 'Request: ', repr(request) > ! traceback.print_exc(file=erf) > ! print>>erf, '\n*** Unrecoverable, server exiting!' > ! print>>erf, '-'*40 > ! import os > ! os._exit Did you mean to call os._exit, ie, os._exit()? Otherwise this doesn't seem to have any effect. Neal From kbk@users.sourceforge.net Sat Mar 22 19:40:21 2003 From: kbk@users.sourceforge.net (Kurt B. Kaiser) Date: Sat, 22 Mar 2003 11:40:21 -0800 Subject: [Idle-dev] CVS: idle PyShell.py,1.58,1.59 run.py,1.13,1.14 Message-ID: Update of /cvsroot/idlefork/idle In directory sc8-pr-cvs1:/tmp/cvs-serv26496 Modified Files: PyShell.py run.py Log Message: M PyShell.py M run.py 1. Move subprocess socket handling to a subthread - "SockThread". 2. In the subprocess, implement a queue and global completion and exit flags. Execute code after it is passed through the queue. (Currently, user code is executed in SockThread. The next phase of development will move the tail of the queue to MainThread.) 3. Implement an RPC message used to shut down the execution server. 4. Improve normal and exception subprocess exits. (At this checkin a "pass loop" interrupt doesn't work on any platform. It will be restored for all platforms once user code execution is moved to MainThread.) Index: PyShell.py =================================================================== RCS file: /cvsroot/idlefork/idle/PyShell.py,v retrieving revision 1.58 retrieving revision 1.59 diff -C2 -r1.58 -r1.59 *** PyShell.py 10 Mar 2003 20:42:22 -0000 1.58 --- PyShell.py 22 Mar 2003 19:40:18 -0000 1.59 *************** *** 368,383 **** pass # Kill subprocess, spawn a new one, accept connection. - if hasattr(os, 'kill'): - # We can interrupt any loop if we can use SIGINT. This doesn't - # work in Windows, currently we can only interrupt loops doing I/O. - self.__signal_interrupt() - # XXX KBK 13Feb03 Don't close the socket until the interrupt thread - # finishes. - self.tkconsole.executing = False try: self.rpcclt.close() os.wait() except: pass self.spawn_subprocess() self.rpcclt.accept() --- 368,379 ---- pass # Kill subprocess, spawn a new one, accept connection. try: + self.interrupt_subprocess() + self.shutdown_subprocess() self.rpcclt.close() os.wait() except: pass + self.tkconsole.executing = False self.spawn_subprocess() self.rpcclt.accept() *************** *** 407,414 **** def __request_interrupt(self): ! self.rpcclt.asynccall("exec", "interrupt_the_server", (), {}) def interrupt_subprocess(self): ! if hasattr(os, "kill"): self.__signal_interrupt() else: --- 403,415 ---- def __request_interrupt(self): ! try: ! self.rpcclt.asynccall("exec", "interrupt_the_server", (), {}) ! except: ! pass def interrupt_subprocess(self): ! # XXX KBK 22Mar03 Use interrupt message on all platforms for now. ! # XXX if hasattr(os, "kill"): ! if False: self.__signal_interrupt() else: *************** *** 417,420 **** --- 418,432 ---- threading.Thread(target=self.__request_interrupt).start() + def __request_shutdown(self): + try: + self.rpcclt.asynccall("exec", "shutdown_the_server", (), {}) + except: + pass + + def shutdown_subprocess(self): + t = threading.Thread(target=self.__request_shutdown) + t.start() + t.join() + def transfer_path(self): self.runcommand("""if 1: *************** *** 469,475 **** def kill_subprocess(self): clt = self.rpcclt - self.rpcclt = None if clt is not None: clt.close() debugger = None --- 481,488 ---- def kill_subprocess(self): clt = self.rpcclt if clt is not None: + self.shutdown_subprocess() clt.close() + self.rpcclt = None debugger = None Index: run.py =================================================================== RCS file: /cvsroot/idlefork/idle/run.py,v retrieving revision 1.13 retrieving revision 1.14 diff -C2 -r1.13 -r1.14 *** run.py 11 Mar 2003 22:55:56 -0000 1.13 --- run.py 22 Mar 2003 19:40:19 -0000 1.14 *************** *** 3,6 **** --- 3,8 ---- import socket import traceback + import threading + import Queue import boolcheck *************** *** 11,17 **** --- 13,30 ---- import StackViewer import rpc + import interrupt import __main__ + # Thread shared globals: Establish a queue between a subthread (which handles + # the socket) and the main thread (which runs user code), plus global + # completion and exit flags: + + server = None # RPCServer instance + queue = Queue.Queue(0) + execution_finished = False + exit_requested = False + + def main(): """Start the Python execution server in a subprocess *************** *** 21,25 **** the mix-in class SocketIO. ! When the RPCServer svr is instantiated, the TCPServer initialization creates an instance of run.MyHandler and calls its handle() method. handle() instantiates a run.Executive object, passing it a reference to the --- 34,38 ---- the mix-in class SocketIO. ! When the RPCServer 'server' is instantiated, the TCPServer initialization creates an instance of run.MyHandler and calls its handle() method. handle() instantiates a run.Executive object, passing it a reference to the *************** *** 32,44 **** """ port = 8833 if sys.argv[1:]: port = int(sys.argv[1]) sys.argv[:] = [""] ! addr = ("localhost", port) for i in range(6): time.sleep(i) try: ! svr = rpc.RPCServer(addr, MyHandler) break except socket.error, err: --- 45,77 ---- """ + global queue, execution_finished, exit_requested + port = 8833 if sys.argv[1:]: port = int(sys.argv[1]) sys.argv[:] = [""] ! sockthread = threading.Thread(target=manage_socket, ! name='SockThread', ! args=(('localhost', port),)) ! sockthread.setDaemon(True) ! sockthread.start() ! while 1: ! try: ! if exit_requested: ! sys.exit() ! # XXX KBK 22Mar03 eventually check queue here! ! pass ! time.sleep(0.05) ! except KeyboardInterrupt: ! ##execution_finished = True ! continue ! ! def manage_socket(address): ! global server, exit_requested ! for i in range(6): time.sleep(i) try: ! server = rpc.RPCServer(address, MyHandler) break except socket.error, err: *************** *** 50,59 **** else: print>>sys.__stderr__, "\nConnection to Idle failed, exiting." ! sys.exit() ! svr.handle_request() # A single request only class MyHandler(rpc.RPCHandler): def handle(self): executive = Executive(self) self.register("exec", executive) --- 83,94 ---- else: print>>sys.__stderr__, "\nConnection to Idle failed, exiting." ! exit_requested = True ! server.handle_request() # A single request only ! class MyHandler(rpc.RPCHandler): def handle(self): + """Override base method""" executive = Executive(self) self.register("exec", executive) *************** *** 61,65 **** sys.stdout = self.get_remote_proxy("stdout") sys.stderr = self.get_remote_proxy("stderr") ! rpc.RPCHandler.handle(self) class Executive: --- 96,101 ---- sys.stdout = self.get_remote_proxy("stdout") sys.stderr = self.get_remote_proxy("stderr") ! rpc.RPCHandler.getresponse(self, myseq=None, wait=0.5) ! class Executive: *************** *** 71,74 **** --- 107,129 ---- def runcode(self, code): + global queue, execution_finished + + execution_finished = False + queue.put(code) + # dequeue and run in subthread + self.runcode_from_queue() + while not execution_finished: + time.sleep(0.05) + + def runcode_from_queue(self): + global queue, execution_finished + + # poll until queue has code object, using threads, just block? + while True: + try: + code = queue.get(0) + break + except Queue.Empty: + time.sleep(0.05) try: exec code in self.locals *************** *** 86,90 **** for line in lines: print>>efile, line, ! self.flush_stdout() def flush_stdout(self): --- 141,148 ---- for line in lines: print>>efile, line, ! execution_finished = True ! else: ! self.flush_stdout() ! execution_finished = True def flush_stdout(self): *************** *** 127,133 **** def interrupt_the_server(self): - # XXX KBK 05Feb03 Windows requires this be done with messages and - # threads.... self.rpchandler.interrupted = True def start_the_debugger(self, gui_adap_oid): --- 185,196 ---- def interrupt_the_server(self): self.rpchandler.interrupted = True + ##print>>sys.__stderr__, "** Interrupt main!" + interrupt.interrupt_main() + + def shutdown_the_server(self): + global exit_requested + + exit_requested = True def start_the_debugger(self, gui_adap_oid): From kbk@shore.net Sat Mar 22 20:06:34 2003 From: kbk@shore.net (Kurt B. Kaiser) Date: Sat, 22 Mar 2003 15:06:34 -0500 Subject: [Idle-dev] CVS: idle rpc.py,1.20,1.21 In-Reply-To: <20030322194015.GE25722@epoch.metaslash.com> (Neal Norwitz's message of "Sat, 22 Mar 2003 14:40:15 -0500") References: <20030322194015.GE25722@epoch.metaslash.com> Message-ID: Neal Norwitz writes: >> ! except: >> ! erf = 'sys.__stderr__' >> ! print>>erf, '-'*40 >> ! print>>erf, 'Unhandled server exception!' >> ! print>>erf, 'Thread: %s' % threading.currentThread().getName() >> ! print>>erf, 'Client Address: ', address >> ! print>>erf, 'Request: ', repr(request) >> ! traceback.print_exc(file=erf) >> ! print>>erf, '\n*** Unrecoverable, server exiting!' >> ! print>>erf, '-'*40 >> ! import os >> ! os._exit > > Did you mean to call os._exit, ie, os._exit()? Otherwise this doesn't > seem to have any effect. Yes, thanks! There were some other problems, also. I must have "polished" it after testing it. -- KBK From kbk@users.sourceforge.net Sat Mar 22 20:11:17 2003 From: kbk@users.sourceforge.net (Kurt B. Kaiser) Date: Sat, 22 Mar 2003 12:11:17 -0800 Subject: [Idle-dev] CVS: idle rpc.py,1.21,1.22 Message-ID: Update of /cvsroot/idlefork/idle In directory sc8-pr-cvs1:/tmp/cvs-serv4340 Modified Files: rpc.py Log Message: Correct error in last checkin noticed by Neal Norwitz. And some more. Index: rpc.py =================================================================== RCS file: /cvsroot/idlefork/idle/rpc.py,v retrieving revision 1.21 retrieving revision 1.22 diff -C2 -r1.21 -r1.22 *** rpc.py 22 Mar 2003 19:15:58 -0000 1.21 --- rpc.py 22 Mar 2003 20:11:14 -0000 1.22 *************** *** 102,110 **** pass except: ! erf = 'sys.__stderr__' ! print>>erf, '-'*40 print>>erf, 'Unhandled server exception!' print>>erf, 'Thread: %s' % threading.currentThread().getName() ! print>>erf, 'Client Address: ', address print>>erf, 'Request: ', repr(request) traceback.print_exc(file=erf) --- 102,110 ---- pass except: ! erf = sys.__stderr__ ! print>>erf, '\n' + '-'*40 print>>erf, 'Unhandled server exception!' print>>erf, 'Thread: %s' % threading.currentThread().getName() ! print>>erf, 'Client Address: ', client_address print>>erf, 'Request: ', repr(request) traceback.print_exc(file=erf) *************** *** 112,116 **** print>>erf, '-'*40 import os ! os._exit --- 112,116 ---- print>>erf, '-'*40 import os ! os._exit(0) From harri@nerim.net Sun Mar 23 09:07:43 2003 From: harri@nerim.net (Harri Pasanen) Date: Sun, 23 Mar 2003 10:07:43 +0100 Subject: [Idle-dev] Known bug? Saving fails in IDLE if accents used in characters Message-ID: <200303231007.43259.harri@nerim.net> Hi, In Python 2.2.1, Mandrake 9.0, and Python 2.2.2 on Windows 2000/Win98 trying out IDLE, I'm observing the following: File->New Window Type: # déjà Save: t.py --> Exception in Tkinter callback Traceback (most recent call last): File "/usr/lib/python2.2/lib-tk/Tkinter.py", line 1292, in __call__ return apply(self.func, args) File "/usr/lib/python2.2/site-packages/idle/IOBinding.py", line 126, in save self.save_as(event) File "/usr/lib/python2.2/site-packages/idle/IOBinding.py", line 136, in save_as if self.writefile(filename): File "/usr/lib/python2.2/site-packages/idle/IOBinding.py", line 154, in writefile f.write(chars) UnicodeError: ASCII encoding error: ordinal not in range(128) ------------ In browsing the bugs, I saw some related problems but not exactly this one. It was actually my 12 year old son who found this problem - he wanted to learn programming, so I pointed him to IDLE, and a tutorial in French (http://www.p3b.org/tutor/denis), but the experience was not so rewarding due to this bug. So now he is playing with XEmacs + python, but I'm not sure if that is the best novice environment. Regards, Harri From neal@metaslash.com Sun Mar 23 13:04:39 2003 From: neal@metaslash.com (Neal Norwitz) Date: Sun, 23 Mar 2003 08:04:39 -0500 Subject: [Idle-dev] Known bug? Saving fails in IDLE if accents used in characters In-Reply-To: <200303231007.43259.harri@nerim.net> References: <200303231007.43259.harri@nerim.net> Message-ID: <20030323130439.GJ25722@epoch.metaslash.com> On Sun, Mar 23, 2003 at 10:07:43AM +0100, Harri Pasanen wrote: [bug report deleted] Harri: IDLE is in the process of being replaced with IDLEfork Many problems have been fixed in this version. IDLEfork also has many improvements. Could you please try IDLEfork? It is planned to become IDLE in Python 2.3 (and possibly 2.2.3). Regards, Neal From guido@python.org Sun Mar 23 13:08:45 2003 From: guido@python.org (Guido van Rossum) Date: Sun, 23 Mar 2003 08:08:45 -0500 Subject: [Idle-dev] Known bug? Saving fails in IDLE if accents used in characters In-Reply-To: "Your message of Sun, 23 Mar 2003 10:07:43 +0100." <200303231007.43259.harri@nerim.net> References: <200303231007.43259.harri@nerim.net> Message-ID: <200303231308.h2ND8j804098@pcp02138704pcs.reston01.va.comcast.net> Hi Harri! > In Python 2.2.1, Mandrake 9.0, and Python 2.2.2 on Windows 2000/Win98 > trying out IDLE, I'm observing the following: [Saving buffers containing non-ASCII characters doesn't work] The version of IDLE that comes with Python 2.3 (currently in alpha, see python.org/2.3) deals with this problem. It should also be solved in IDLEfork, also in alpha, see idlefork.sf.net). Python 2.3 will eventually adopt IDLEfork as the standard IDLE version; I think IDLEfork also works with Python 2.2. --Guido van Rossum (home page: http://www.python.org/~guido/) From harri@nerim.net Sun Mar 23 16:08:59 2003 From: harri@nerim.net (Harri Pasanen) Date: Sun, 23 Mar 2003 17:08:59 +0100 Subject: [Idle-dev] Known bug? Saving fails in IDLE if accents used in characters In-Reply-To: <200303231308.h2ND8j804098@pcp02138704pcs.reston01.va.comcast.net> References: <200303231007.43259.harri@nerim.net> <200303231308.h2ND8j804098@pcp02138704pcs.reston01.va.comcast.net> Message-ID: <200303231709.00128.harri@nerim.net> On Sunday 23 March 2003 14:08, Guido van Rossum wrote: > Hi Harri! > Hi Guido, as you can see I'm busy raising a second generation of Python programmers ;-). The rest mainly for the IDLEfork people: I gave IDLEfork 0.9a2 a go, and it sort-of tries to deal with the problem. Saving my python file, still consisting of the single line # déjà it spits out a message box with a title "I/O Error" Non-ASCII found, yet no encoding declared. Add a line like #-*- coding: iso-8859-15-*- to your file [OK] After clicking OK, it seems to save my file without problems, but it bugs me with the message at each save. The message box is modal, and I cannot cut and paste the line from it. Typing it in manually, my next I/O Error is: Unknown encoding iso-8859-15-. Saving as UTF-8 [OK] Now this is the greatest, as trying to run the resulting file in python gives: [harri@kapu harri]$ python t.py File "t.py", line 1 #-*- coding: iso-8859-15-*- ^ SyntaxError: invalid syntax Hmm... Perl seems to to have a pragma to enable UTF-8 in source code, but I was not aware Python would have support for UTF-8 source. Does it? Now how about doing what 99% of other editors do, and supporting by default iso-8859-15 (basically latin-1), that will make get a couple of hundred million Europeans happy right there? I remember having to trouble with 7-bit ASCII only sometime in 1970's -- loong time ago. Extending the support outside of latin alphabets is an honorable goal, but clearly what ever the encoding is should not munge with the python source code, unless python itself has support for it. The following link has some info on how Java deals with this issue: http://www.jorendorff.com/articles/unicode/java.html (basically the java compiler does support multiple charsets). All my sympathy for the Japanese/Chinese/... there, how do you program in python/C/C++? I would assume externalizing the strings would be the easiest, or are there specialized editors that handle gracefully non-ASCII, non-Latin comments and strings inside ASCII source code? I'm curious to know. Sorry for this long rant, just trying to be a good father... ;-) Harri From loewis@informatik.hu-berlin.de Sun Mar 23 22:33:51 2003 From: loewis@informatik.hu-berlin.de (Martin von Loewis) Date: Sun, 23 Mar 2003 23:33:51 +0100 (CET) Subject: Harri Pasanen: Re: [Idle-dev] Known bug? Saving fails in IDLE if accents used in char acters In-Reply-To: <200303232051.h2NKpGI04782@pcp02138704pcs.reston01.va.comcast.net> from Guido van Rossum at "Mar 23, 2003 03:51:15 pm" Message-ID: <200303232233.h2NMXpXd013173@paros.informatik.hu-berlin.de> > Saving my python file, still consisting of the single line > # d=E9j=E0 >=20 > it spits out a message box with a title "I/O Error" > Non-ASCII found, yet no encoding declared. Add a line like=20 > #-*- coding: iso-8859-15-*- > to your file [OK] >=20 > After clicking OK, it seems to save my file without problems, but it=20 > bugs me with the message at each save. Hi Harry, There is not much we can do about this; IDLE *could* try to edit the file for you, but I consider this too intrusive, hence the error message. > The message box is modal, and I cannot cut and paste the line from it. Patches to correct this are welcome. I'm unsure what Tk widget to use that allows copyable-but-uneditable text. > Typing it in manually, my next I/O Error is: >=20 > Unknown encoding iso-8859-15-. > Saving as UTF-8 > [OK] Are you sure there was no space between the 5 and the - in the message? Adding a space should help. > Now this is the greatest, as trying to run the resulting file in=20 > python gives: >=20 > [harri@kapu harri]$ python t.py > File "t.py", line 1 > =EF=BB=BF#-*- coding: iso-8859-15-*- > ^ > SyntaxError: invalid syntax Yes, this won't be a syntax error only in Python 2.3. If you correct the problem of the encoding declaration being incorrect (by adding the missing space), the problem will go away. > Hmm... Perl seems to to have a pragma to enable UTF-8 in source code,=20 > but I was not aware Python would have support for UTF-8 source. Does=20 > it? Indeed; this is the result of PEP 263. Unlike Perl, Python supports multiple different source encoding, hence the need for an explicit declaration. > Now how about doing what 99% of other editors do, and supporting by=20 > default iso-8859-15 (basically latin-1), that will make get a couple=20 > of hundred million Europeans happy right there? =20 Supporting this in IDLE would be acceptable, I guess. However, in the long run, Python itself will refuse source code that lacks a proper encoding declaration, so I felt that IDLE should teach users how to do that early on. > Extending the support outside of latin alphabets is an honorable goal,=20 > but clearly what ever the encoding is should not munge with the=20 > python source code, unless python itself has support for it. But Python does have support for it. > The following link has some info on how Java deals with this issue:=20 > http://www.jorendorff.com/articles/unicode/java.html (basically the=20 > java compiler does support multiple charsets). So does Python. However, the Java method is fundamentally flawed: Whoever invokes javac needs to know what the source encoding is, and it needs to be the same for all source code files. I find it=20 unacceptable that users of a library have to know what encoding the library uses. In any case, I recommend to read PEP 263. > All my sympathy for the Japanese/Chinese/... there, how do you=20 > program in python/C/C++? I would assume externalizing the strings=20 > would be the easiest, or are there specialized editors that handle=20 > gracefully non-ASCII, non-Latin comments and strings inside ASCII=20 > source code? =20 You would think that people do that, but they don't: a) they want to put comments into source code, in their native language, using the encoding that their system uses. b) they want to use non-ASCII in identifiers (not supported in Python 2.3= , but may be supported in the future) c) they do put non-ASCII into string literals and Unicode literals and expect this to work. In particular for Unicode literals, this cannot work without an encoding declaration. If they target a single language only, putting the text into the source is a natural thing to do; the overhead of an external message catalogue is unacceptable. Regards, Martin From neal@metaslash.com Sun Mar 23 23:18:42 2003 From: neal@metaslash.com (Neal Norwitz) Date: Sun, 23 Mar 2003 18:18:42 -0500 Subject: Harri Pasanen: Re: [Idle-dev] Known bug? Saving fails in IDLE if accents used in char acters In-Reply-To: <200303232233.h2NMXpXd013173@paros.informatik.hu-berlin.de> References: <200303232051.h2NKpGI04782@pcp02138704pcs.reston01.va.comcast.net> <200303232233.h2NMXpXd013173@paros.informatik.hu-berlin.de> Message-ID: <20030323231842.GP25722@epoch.metaslash.com> On Sun, Mar 23, 2003 at 11:33:51PM +0100, Martin von Loewis wrote: > > > The message box is modal, and I cannot cut and paste the line from it. > > Patches to correct this are welcome. I'm unsure what Tk widget to use > that allows copyable-but-uneditable text. The entry widget works fine, it needs to be disabled to prevent it from being modified: >>> from Tkinter import * >>> tk = Tk() >>> entry = Entry() >>> entry.pack() >>> entry.insert(0, 'test, test, test') >>> entry.configure(state=DISABLED) Neal From noreply@sourceforge.net Mon Mar 24 09:02:35 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 24 Mar 2003 01:02:35 -0800 Subject: [Idle-dev] [ idlefork-Patches-682347 ] Another locale encoding patch Message-ID: Patches item #682347, was opened at 2003-02-07 15:47 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=309579&aid=682347&group_id=9579 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Kirill Simonov (kirill_simonov) Assigned to: Nobody/Anonymous (nobody) Summary: Another locale encoding patch Initial Comment: This patch is for use with the patch #615312. With this patch, stdin.readline() returns an ordinary string in the locale's encoding, not an Unicode string. ---------------------------------------------------------------------- Comment By: Martin v. Löwis (loewis) Date: 2003-03-24 10:02 Message: Logged In: YES user_id=21627 Reason #2 is obsolete now; raw_input *can* result in Unicode strings in Python 2.3. I can sympathise with the patch. However, I would like to see it combined with a patch to let applications determine the encoding used, e.g. by querying sys.stdin.encoding. Otherwise, getting raw bytes will complicate matters. See also Python patch #612627, which adds the encoding attribute to a terminal stdout. ---------------------------------------------------------------------- Comment By: Kirill Simonov (kirill_simonov) Date: 2003-02-18 00:25 Message: Logged In: YES user_id=36553 There are no such a problem with Idlefork. The author of the post was using the original IDLE from the 2.2 distribution. Note the line in the traceback: File "[...]\Tools\idle\ColorDelegator.py", line 196, in recolorize_main if value in ("def", "class"): The line 196 of ColorDelegator.py from Idlefork 0.9a2 is different. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2003-02-17 23:14 Message: Logged In: YES user_id=149084 Does this solve the problem mentioned in http://mail.python.org/pipermail/idle-dev/2003-February/001628.html ---------------------------------------------------------------------- Comment By: Kirill Simonov (kirill_simonov) Date: 2003-02-07 16:35 Message: Logged In: YES user_id=36553 Two reasons. 1. The following script does not work correctly in IDLE: # -*- encoding: koi8-r -*- name = raw_input("What's your name?") print "Hi %s!" % name I use russian phrases here, of course. And if I enter my name using cyrillic letters, I get UnicodeError. This is because I mixed a Unicode string with with an 8-bit string. I know that I can use unicode literals, but I don't think that my students should know anything about Unicode, 6 cyrrilic encodings, etc, especially when they are writing their first program. Note that this program is absolutely correct and run perfectly from console. So I think that it should work in IDLE too. 2. I believe that raw_input() and stdin.readline() must always return either Unicode strings or 8-bit strings, but do not mix them. P.S. I think that -*- encoding -*- comments are very unfriendly for newbies too, but that's another story. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2003-02-07 15:55 Message: Logged In: YES user_id=6380 Why would you want that? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=309579&aid=682347&group_id=9579 From harri@nerim.net Mon Mar 24 09:00:36 2003 From: harri@nerim.net (Harri Pasanen) Date: Mon, 24 Mar 2003 10:00:36 +0100 Subject: Harri Pasanen: Re: [Idle-dev] Known bug? Saving fails in IDLE if accents used in char acters In-Reply-To: <200303232233.h2NMXpXd013173@paros.informatik.hu-berlin.de> References: <200303232233.h2NMXpXd013173@paros.informatik.hu-berlin.de> Message-ID: <200303241000.36760.harri@nerim.net> On Sunday 23 March 2003 23:33, Martin von Loewis wrote: > > Saving my python file, still consisting of the single line > > # déjà > > > > it spits out a message box with a title "I/O Error" > > Non-ASCII found, yet no encoding declared. Add a line like > > #-*- coding: iso-8859-15-*- > > to your file [OK] > > > > After clicking OK, it seems to save my file without problems, but > > it bugs me with the message at each save. > > Hi Harry, > > There is not much we can do about this; IDLE *could* try to edit > the file for you, but I consider this too intrusive, hence the > error message. > My vote for IDLE inserting the font encoding line to top of file if it does not exist. > > The message box is modal, and I cannot cut and paste the line > > from it. > > Patches to correct this are welcome. I'm unsure what Tk widget to > use that allows copyable-but-uneditable text. > > > Typing it in manually, my next I/O Error is: > > > > Unknown encoding iso-8859-15-. > > Saving as UTF-8 > > [OK] > > Are you sure there was no space between the 5 and the - in the > message? Adding a space should help. You are right, the space helps. But having manually to type the encoding line is prone to errors, that is why I think editors should have built in support for templating that sort of things. Note that the message box is also in a proportional, not fixed font, so spotting the spaces is not obvious. > [snip...] > Indeed; this is the result of PEP 263. Unlike Perl, Python supports > multiple different source encoding, hence the need for an explicit > declaration. > > > Now how about doing what 99% of other editors do, and supporting > > by default iso-8859-15 (basically latin-1), that will make get a > > couple of hundred million Europeans happy right there? > > Supporting this in IDLE would be acceptable, I guess. However, in > the long run, Python itself will refuse source code that lacks a > proper encoding declaration, so I felt that IDLE should teach users > how to do that early on. > But the PEP states: 1. Allow non-ASCII in string literals and comments, by internally treating a missing encoding declaration as a declaration of "iso-8859-1". The current IDLE or IDLEfork does not seem to do above. And what about maintaining legacy python code with IDLE, much of which is in is-8859-1 I suppose? > > Extending the support outside of latin alphabets is an honorable > > goal, but clearly what ever the encoding is should not munge with > > the python source code, unless python itself has support for it. > > But Python does have support for it. > Starting from 2.3 I understand? Thanks for the explanations, PEP 263 is good news to me. Harri From noreply@sourceforge.net Mon Mar 24 09:14:35 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 24 Mar 2003 01:14:35 -0800 Subject: [Idle-dev] [ idlefork-Bugs-708703 ] Missing module interrupt Message-ID: Bugs item #708703, was opened at 2003-03-24 10:14 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=708703&group_id=9579 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Nobody/Anonymous (nobody) Summary: Missing module interrupt Initial Comment: Trying to run the current CVS, I get the error Traceback (most recent call last): File "", line 1, in ? File "run.py", line 15, in ? import interrupt ImportError: No module named interrupt There appears to be no module interrupt anywhere. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=708703&group_id=9579 From noreply@sourceforge.net Mon Mar 24 10:13:19 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Mon, 24 Mar 2003 02:13:19 -0800 Subject: [Idle-dev] [ idlefork-Bugs-708703 ] Missing module interrupt Message-ID: Bugs item #708703, was opened at 2003-03-24 10:14 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=708703&group_id=9579 Category: None Group: None >Status: Closed >Resolution: Invalid Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Nobody/Anonymous (nobody) Summary: Missing module interrupt Initial Comment: Trying to run the current CVS, I get the error Traceback (most recent call last): File "", line 1, in ? File "run.py", line 15, in ? import interrupt ImportError: No module named interrupt There appears to be no module interrupt anywhere. ---------------------------------------------------------------------- >Comment By: Martin v. Löwis (loewis) Date: 2003-03-24 11:13 Message: Logged In: YES user_id=21627 I withdraw this report. I had not expected that IDLE uses extension modules. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=708703&group_id=9579 From loewis@informatik.hu-berlin.de Mon Mar 24 13:55:48 2003 From: loewis@informatik.hu-berlin.de (Martin von Loewis) Date: Mon, 24 Mar 2003 14:55:48 +0100 (CET) Subject: Harri Pasanen: Re: [Idle-dev] Known bug? Saving fails in IDLE if accents used in char acters In-Reply-To: <20030323231842.GP25722@epoch.metaslash.com> from Neal Norwitz at "Mar 23, 2003 06:18:42 pm" Message-ID: <200303241355.h2ODtm9r016101@paros.informatik.hu-berlin.de> > The entry widget works fine, it needs to be disabled to prevent it > from being modified: > > >>> from Tkinter import * > >>> tk = Tk() > >>> entry = Entry() > >>> entry.pack() > >>> entry.insert(0, 'test, test, test') > >>> entry.configure(state=DISABLED) I see. Unfortunately, the code currently uses tkMessageBox, which cannot be customized to use an Entry instead of a label (or message widget), nor can Dialog be customized in this way. I'm now looking into writing a full dialog inheriting from SimpleDialog, completely rewriting its __init__ :-( Regards, Martin From loewis@informatik.hu-berlin.de Mon Mar 24 14:05:42 2003 From: loewis@informatik.hu-berlin.de (Martin von Loewis) Date: Mon, 24 Mar 2003 15:05:42 +0100 (CET) Subject: Harri Pasanen: Re: [Idle-dev] Known bug? Saving fails in IDLE if accents used in char acters In-Reply-To: <200303241000.36760.harri@nerim.net> from Harri Pasanen at "Mar 24, 2003 10:00:36 am" Message-ID: <200303241405.h2OE5gkp016247@paros.informatik.hu-berlin.de> > > There is not much we can do about this; IDLE *could* try to edit > > the file for you, but I consider this too intrusive, hence the > > error message. > > > > My vote for IDLE inserting the font encoding line to top of file if it > does not exist. I'm implementing a change into that direction right now: The dialog will have a button "Edit my text", which does the appropriate editing. > Note that the message box is also in a proportional, not fixed font, > so spotting the spaces is not obvious. I see. I'll try to make this a fixed font, as well. > But the PEP states: > > 1. Allow non-ASCII in string literals and comments, by internally > treating a missing encoding declaration as a declaration of > "iso-8859-1". > > The current IDLE or IDLEfork does not seem to do above. Strictly speaking, this is how Python will *interpret* a file with no encoding declaration; this specific interpretation must be chosen for backwards compatibility with 2.2 (which treats non-ASCII bytes in Unicode literals as Latin-1, which is a flaw that triggered PEP 263). IDLE itself needs different backwards compatibility: People do use non-ASCII non-Latin-1 in Python source code, so IDLE treats "no encoding declaration" as "encoded in the locale's encoding". For the majority of existing code, this is the right approach. Notice that IDLE *does* allow you to use Latin-1 in source code without explicit declaration. Once you press "OK", IDLE will safe the file in the locale's encoding (which is probably Latin-1 or CP 1252 for you). The message box is just a warning, created every time you safe the file - but it will still be safed, and loaded. > And what > about maintaining legacy python code with IDLE, much of which is in > is-8859-1 I suppose? This assumption is incorrect. Kirill Simonov was the first to complain about IDLE not supporting "funny" characters, and he is using Cyrillic in all his files. He would be quite unhappy if IDLE started displaying mojibake to him. > Starting from 2.3 I understand? Correct. Martin From neal@metaslash.com Mon Mar 24 14:10:09 2003 From: neal@metaslash.com (Neal Norwitz) Date: Mon, 24 Mar 2003 09:10:09 -0500 Subject: Harri Pasanen: Re: [Idle-dev] Known bug? Saving fails in IDLE if accents used in char acters In-Reply-To: <200303241355.h2ODtm9r016101@paros.informatik.hu-berlin.de> References: <20030323231842.GP25722@epoch.metaslash.com> <200303241355.h2ODtm9r016101@paros.informatik.hu-berlin.de> Message-ID: <20030324141009.GU25722@epoch.metaslash.com> On Mon, Mar 24, 2003 at 02:55:48PM +0100, Martin von Loewis wrote: > > The entry widget works fine, it needs to be disabled to prevent it > > from being modified: > > > > >>> from Tkinter import * > > >>> tk = Tk() > > >>> entry = Entry() > > >>> entry.pack() > > >>> entry.insert(0, 'test, test, test') > > >>> entry.configure(state=DISABLED) > > I see. Unfortunately, the code currently uses tkMessageBox, > which cannot be customized to use an Entry instead of > a label (or message widget), nor can Dialog be customized > in this way. I'm now looking into writing a full dialog > inheriting from SimpleDialog, completely rewriting its > __init__ :-( Could you use tkSimpleDialog._QueryString and replace the body method? The body would need to set the string and disable the entry. Might need to use another kwarg for the string. Neal From harri@nerim.net Mon Mar 24 15:04:17 2003 From: harri@nerim.net (Harri Pasanen) Date: Mon, 24 Mar 2003 16:04:17 +0100 Subject: Harri Pasanen: Re: [Idle-dev] Known bug? Saving fails in IDLE if accents used in char acters In-Reply-To: <200303241405.h2OE5gkp016247@paros.informatik.hu-berlin.de> References: <200303241405.h2OE5gkp016247@paros.informatik.hu-berlin.de> Message-ID: <200303241604.17307.harri@nerim.net> On Monday 24 March 2003 15:05, Martin von Loewis wrote: > > > My vote for IDLE inserting the font encoding line to top of file > > if it does not exist. > > I'm implementing a change into that direction right now: The dialog > will have a button "Edit my text", which does the appropriate > editing. > Considering 95% of the people are probably not concerned about other codesets than their own, locale's codeset, how does the following sound: File->New Window would create automatically the first line with the locale's encoding. Further extension would be to have the default codeset selectionable, or disabled, from the Options menu. Harri From noreply@sourceforge.net Thu Mar 27 14:10:52 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Thu, 27 Mar 2003 06:10:52 -0800 Subject: [Idle-dev] [ idlefork-Patches-710733 ] Improving source encoding dialog Message-ID: Patches item #710733, was opened at 2003-03-27 15:10 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=309579&aid=710733&group_id=9579 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Nobody/Anonymous (nobody) Summary: Improving source encoding dialog Initial Comment: This patch improves the error message a user gets when saving a file with non-ASCII characters, and no source encoding is specified. It does so by: - adding a dialog EncodingMessage, which contains the line to add in a fixed-font entry widget, and which has a button to add that line to the file automatically. - adding a configuration option EditorWindow/encoding, which has three possible values: none, utf-8, and locale. none is the default; IDLE will show this dialog when non-ASCII characters are encountered. utf-8 means that files with non-ASCII characters are saved as utf-8-with-bom. locale means that files are saved in the locale's encoding; the dialog is only display if the source contains characters outside the locale's charset. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=309579&aid=710733&group_id=9579 From noreply@sourceforge.net Mon Mar 31 05:23:24 2003 From: noreply@sourceforge.net (SourceForge.net) Date: Sun, 30 Mar 2003 21:23:24 -0800 Subject: [Idle-dev] [ idlefork-Patches-710733 ] Improving source encoding dialog Message-ID: Patches item #710733, was opened at 2003-03-27 09:10 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=309579&aid=710733&group_id=9579 Category: None Group: None Status: Open >Resolution: Accepted Priority: 5 Submitted By: Martin v. Löwis (loewis) >Assigned to: Kurt B. Kaiser (kbk) Summary: Improving source encoding dialog Initial Comment: This patch improves the error message a user gets when saving a file with non-ASCII characters, and no source encoding is specified. It does so by: - adding a dialog EncodingMessage, which contains the line to add in a fixed-font entry widget, and which has a button to add that line to the file automatically. - adding a configuration option EditorWindow/encoding, which has three possible values: none, utf-8, and locale. none is the default; IDLE will show this dialog when non-ASCII characters are encountered. utf-8 means that files with non-ASCII characters are saved as utf-8-with-bom. locale means that files are saved in the locale's encoding; the dialog is only display if the source contains characters outside the locale's charset. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=309579&aid=710733&group_id=9579 From david@rebirthing.co.nz Mon Mar 31 13:12:52 2003 From: david@rebirthing.co.nz (David McNab) Date: 01 Apr 2003 01:12:52 +1200 Subject: [Idle-dev] Help - Debugger key bindings Message-ID: <1049116372.1518.20.camel@rebirth> Hi, I'm trying to hack the IDLE debugger so that the Step, Over, Out etc buttons can be triggered with keystrokes (to ease my aching mouse finger). There's really nothing worse than the pain of having to click the mouse repeatedly for every step while debugging - keystrokes are far easier. I've been partly successful - in Debugger.py, make_gui(), I've added: self.top.bind("", self.step) and to avoid an arguments mismatch, I've changed step: def step(self, arg=None) There's only one problem - when I press Alt-9, the step happens fine. However, window focus changes to the source window, which means I have to either click the debug pane again with the mouse, or press Alt-Tab to switch focus. Can someone please advise if there's any way to switch focus back to the debug frame from within Debugger.step() ? All help appreciated. Cheers David