From glingl@aon.at Sun Sep 1 23:01:29 2002 From: glingl@aon.at (Gregor Lingl) Date: Mon, 02 Sep 2002 00:01:29 +0200 Subject: [Idle-dev] Help concerning raw_input urgently needed! References: <20020901005656.GA5950@micromuse.com> <20020901214106.GC5950@micromuse.com> Message-ID: <3D728E39.9010204@aon.at> Some ten days ago I posted the following to idle-dev, but the message went into a wrong thread and was consequently ignored. So I try it again, this time also at tutor. Several colleagues asked me already, why this Error occurs - I still can only reply: I don't know. By the way: does this Error also occur when working with IDLE on a Linux-machine? (Aren't there people with happy little Linux-Systems in Berlin, who could check this easily?) -------------- Some month ago I copied sitecustomize.py with appropriate locale-setting to C:\Python22\Lib thanks to an advice of someone on this list. This worked well until today I made the observation, that raw_input doesn't work correctly: >>> a = raw_input("Hä? ") Hä? Tschüs Traceback (most recent call last): File "", line 1, in ? a = raw_input("Hä? ") TypeError: object.readline() returned non-string >>> Consequently I cannot execute programs with raw_input from IDLE, if the expected answers (inputs) may contain "Umlaute". Those same programs, however, can be executed from the commandline. And also the interactive Python interpreter can execute raw_input statements even when Umlaute are input. So I think, this must be a problem of IDLE. I must confess, I do not understand the error message. Hope this can be corrected somehow. Thanks Gregor Lingl From kyle@sent.com Sun Sep 1 23:51:20 2002 From: kyle@sent.com (Kyle Babich) Date: Sun, 1 Sep 2002 22:51:20 UT Subject: [Idle-dev] Re: [Tutor] Help concerning raw_input urgently needed! Message-ID: <20020901225120.D9FA19370B@server2.fastmail.fm> On Mon, 02 Sep 2002 00:01:29 +0200, "Gregor Lingl" said: > Some ten days ago I posted the following to idle-dev, but > the message went into a wrong thread and was consequently > ignored. So I try it again, this time also at tutor. Several colleagues > asked me already, why this Error occurs - I still can only reply: > I don't know. > By the way: does this Error also occur when working with IDLE on > a Linux-machine? (Aren't there people with happy little Linux-Systems > in Berlin, who could check this easily?) > -------------- >=20 > Some month ago I copied sitecustomize.py with > appropriate locale-setting to C:\Python22\Lib > thanks to an advice of someone on this list. >=20 > This worked well until today I made the observation, > that raw_input doesn't work correctly: >=20 > >>> a =3D raw_input("H=E4? ") > H=E4? Tsch=FCs > Traceback (most recent call last): > File "", line 1, in ? > a =3D raw_input("H=E4? ") > TypeError: object.readline() returned non-string > >>> >=20 The program expects the raw_input to return a string, but Tsch=FCs according to python doesn't qualify. >>> type("Tsch=FCs") UnicodeError: ASCII encoding error: ordinal not in range(128) A better idea might be to use sys.stdin.readline(). >>> import sys >>> a =3D sys.stdin.readline() Tsch=FCs >>> print a Tsch=FCs > Consequently I cannot execute programs with > raw_input from IDLE, if the expected answers (inputs) > may contain "Umlaute". Those same programs, > however, can be executed from the commandline. > And also the interactive Python interpreter can execute > raw_input statements even when Umlaute are input. >=20 > So I think, this must be a problem of IDLE. > I must confess, I do not understand the error message. >=20 > Hope this can be corrected somehow. > Thanks >=20 > Gregor Lingl >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > Tutor maillist - Tutor@python.org > http://mail.python.org/mailman/listinfo/tutor >=20 From guillermo.fernandez@epfl.ch Mon Sep 2 01:06:21 2002 From: guillermo.fernandez@epfl.ch (Guillermo Fernandez) Date: Mon, 02 Sep 2002 09:36:21 +0930 Subject: [Idle-dev] Re: [Tutor] Help concerning raw_input urgently needed! References: <20020901005656.GA5950@micromuse.com> <20020901214106.GC5950@micromuse.com> <3D728E39.9010204@aon.at> Message-ID: <3D72AB7D.12847680@epfl.ch> > Some month ago I copied sitecustomize.py with > appropriate locale-setting to C:\Python22\Lib > thanks to an advice of someone on this list. > = > This worked well until today I made the observation, > that raw_input doesn't work correctly: > = > >>> a =3D raw_input("H=E4? ") > H=E4? Tsch=FCs > Traceback (most recent call last): > File "", line 1, in ? > a =3D raw_input("H=E4? ") > TypeError: object.readline() returned non-string > >>> > By the way: does this Error also occur when working with IDLE on > a Linux-machine? (Aren't there people with happy little Linux-Systems > in Berlin, who could check this easily?) I'm in Australia, not in Berlin, but hope this helps :-) I'm using linux SuSE 7.3 with Python 2.2 and this is the result: >>> a =3D raw_input("H=E4? ") UnicodeError: ASCII encoding error: ordinal not in range(128) >>> = >>> Regards, Guille From glingl@aon.at Mon Sep 2 07:54:32 2002 From: glingl@aon.at (Gregor Lingl) Date: Mon, 02 Sep 2002 08:54:32 +0200 Subject: [Idle-dev] Re: [Tutor] Help concerning raw_input urgently needed! References: <20020901225120.D9FA19370B@server2.fastmail.fm> Message-ID: <3D730B28.4030402@aon.at> Kyle Babich schrieb: >On Mon, 02 Sep 2002 00:01:29 +0200, "Gregor Lingl" >said: > > >>... >>Some month ago I copied sitecustomize.py with >>appropriate locale-setting to C:\Python22\Lib >>thanks to an advice of someone on this list. >> >>This worked well until today I made the observation, >>that raw_input doesn't work correctly: >> >> >>> a = raw_input("Hä? ") >>Hä? Tschüs >>Traceback (most recent call last): >> File "", line 1, in ? >> a = raw_input("Hä? ") >>TypeError: object.readline() returned non-string >> >>> >> >> >> > >The program expects the raw_input to return a string, but Tschüs >according to python doesn't qualify. > > > >>>>type("Tschüs") >>>> >>>> >UnicodeError: ASCII encoding error: ordinal not in range(128) > > That's what Python does, if not "sitecustomized". If I put the lines import sys, locale loc = locale.getdefaultlocale() if loc[1]: encoding = loc[1] if encoding != "ascii": sys.setdefaultencoding(encoding) into the file sitecustomize.py this is repaired and type("Tschüs") as well as ather output with öäßÜ and so on works well. Nevertheless there remains the fact that - as shown above - raw_input("Hä? ") does write Hä!, does wait for input, but does NOT accept Tschüs as input. Moreover this occurs only within IDLE, not when using the python-interactive-interpreter. >A better idea might be to use sys.stdin.readline(). > > >>>>import sys >>>>a = sys.stdin.readline() >>>> >>>> >Tschüs > > >>>>print a >>>> >>>> >Tschüs > > > This works also on my machine - so it's a possible solution. Nevertheless I'd prefer much if the IDLE-bug could be repaired, e.g. by some other sort of customizing, because in the lessons for beginning programmers, where I use it, the introduction and explanation of sys.stdin.readline() would distract from the main themes covered there. Moreover it doesn't look fine, if - on a very introductory level - you have to learn how to work around bugs. Nevertheless: thanks so far, it constitutes some progress - better this way than no way. With kind regards Gregor P.S.: To have to use something successfully or to have to explain something to others successfully makes a *big* difference. From magnus@thinkware.se Mon Sep 2 10:08:11 2002 From: magnus@thinkware.se (Magnus Lycka) Date: Mon, 02 Sep 2002 11:08:11 +0200 Subject: [Idle-dev] Re: [Tutor] Help concerning raw_input urgently needed! In-Reply-To: <3D730B28.4030402@aon.at> References: <20020901225120.D9FA19370B@server2.fastmail.fm> Message-ID: <5.1.0.14.0.20020902101532.02b438b8@www.thinkware.se> At 08:54 2002-09-02 +0200, Gregor Lingl wrote: >Moreover this occurs only within IDLE, not when using the=20 >python-interactive-interpreter. I think the problem is that Tcl/Tk use Unicode these days, and Python defaults to ISO8859-1. Thus your umlaut is ok for raw_input in python proper. In IDLE, the characters are recieved by Tk, and translated from Unicode. That fails on any non-ASCII value, since these are ambiguous unless a code page is supplied. I've stumbled over similar Unicode/ASCII problems before with IDLE. There has also been bugs previously that made it impossible to enter floats such as "pi =3D 3.14" if the national settings in Windows assumed decimal comma, such as in Swedish settings etc. I didn't get a lot of response reagarding those problems. (That was before IDLE was a "project".) Maybe there were good and simple solutions for these things, but I sure didn't manage to find them, and I didn't manage to get any attention. It's seems the idle-dev mailing list is equally uninterested now. In general I find it difficult to find good information about internationalization and localization issues for Python. Neither in books, on the net, nor in mailing lists. Maybe it would work better if I was fluent in German or Japanese... ;) After all most of those who write in English don't need to worry about it... My advice would be to avoid IDLE. I prefer PythonWin in Windows, and there are several other environments that are better than IDLE in my opinion. I think Tcl/Tk makes life harder for us. In general I also suggest using wxPython rather than Tkinter. One good reason for that is the rapid development and response to bugs from Robin Dunn and others in the wxPython mailing list. wxWindows and wxPython are not without flaws, but they both have dynamic and responsive development communities that work well, and are helpful for all levels of users. I expect there to be a free IDLE killer in the wxPython package eventually. PyCrust is a beginning. I haven't used IDLE or Tkinter a lot in quite some time, so maybe things changed and I didn't notice, but I feel confident in the growth and development of wxPython. I also miss a "Tkinter development community". Fredrik Lundh doesn't count as a community. ;-) In the long run, I guess we will see a unicodification of our entire computer platforms, and hopefully some of these problems will disappear, but it seems we are in a looong phase of transition, and that certainly makes life a bit complicated for us with more the 26 letters. --=20 Magnus Lyck=E5, Thinkware AB =C4lvans v=E4g 99, SE-907 50 UME=C5 tel: 070-582 80 65, fax: 070-612 80 65 http://www.thinkware.se/ mailto:magnus@thinkware.se From guido@python.org Mon Sep 2 15:09:56 2002 From: guido@python.org (Guido van Rossum) Date: Mon, 02 Sep 2002 10:09:56 -0400 Subject: [Idle-dev] Re: [Tutor] Help concerning raw_input urgently needed! In-Reply-To: Your message of "Mon, 02 Sep 2002 11:08:11 +0200." <5.1.0.14.0.20020902101532.02b438b8@www.thinkware.se> References: <20020901225120.D9FA19370B@server2.fastmail.fm> <5.1.0.14.0.20020902101532.02b438b8@www.thinkware.se> Message-ID: <200209021409.g82E9uZ30689@pcp02138704pcs.reston01.va.comcast.net> > I think the problem is that Tcl/Tk use Unicode these days, > and Python defaults to ISO8859-1. That's not true. > Thus your umlaut is ok for raw_input in python proper. In IDLE, the > characters are recieved by Tk, and translated from Unicode. That > fails on any non-ASCII value, since these are ambiguous unless a > code page is supplied. Try the IDLE from current CVS. AFAIK the Unicode issues have been fixed there. --Guido van Rossum (home page: http://www.python.org/~guido/) From pobrien@orbtech.com Mon Sep 2 15:26:08 2002 From: pobrien@orbtech.com (Patrick K. O'Brien) Date: Mon, 2 Sep 2002 09:26:08 -0500 Subject: [Idle-dev] Re: [Tutor] Help concerning raw_input urgently needed! In-Reply-To: <5.1.0.14.0.20020902101532.02b438b8@www.thinkware.se> Message-ID: [Magnus Lycka] > > PyCrust is a beginning. Thanks for the plug and the opportunity to jump in here and mention that PyCrust has several non-English users who have helped me make PyCrust international language friendly. The PyCrust that is currently in CVS, and that will ship with the next release of wxPython (version 2.3.3), does support your original example: Welcome To PyCrust 0.7.2 - The Flakiest Python Shell Sponsored by Orbtech - Your source for Python programming expertise. Python 2.2.1 (#34, Apr 9 2002, 19:34:33) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. Startup script executed: C:\Code\.pythonrc.py >>> a = raw_input("Hä? ") Hä? Tschüs >>> a 'Tsch\xfcs' >>> print a Tschüs >>> Also, I did *not* need to create a sitecustomize.py file for this to work. That said, IDLE is still getting worked on and hopefully this issue will be addressed. -- Patrick K. O'Brien Orbtech ----------------------------------------------- "Your source for Python programming expertise." ----------------------------------------------- Web: http://www.orbtech.com/web/pobrien/ Blog: http://www.orbtech.com/blog/pobrien/ Wiki: http://www.orbtech.com/wiki/PatrickOBrien ----------------------------------------------- From pobrien@orbtech.com Mon Sep 2 15:30:20 2002 From: pobrien@orbtech.com (Patrick K. O'Brien) Date: Mon, 2 Sep 2002 09:30:20 -0500 Subject: [Idle-dev] Re: [Tutor] Help concerning raw_input urgently needed! In-Reply-To: <200209021409.g82E9uZ30689@pcp02138704pcs.reston01.va.comcast.net> Message-ID: [Guido van Rossum] > > Try the IDLE from current CVS. AFAIK the Unicode issues have been > fixed there. I just updated from CVS and gave it a try. :-( Python 2.2.1 (#34, Apr 9 2002, 19:34:33) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. GRPC IDLE Fork 0.8.2 >>> a = raw_input("Hä? ") UnicodeError: ASCII encoding error: ordinal not in range(128) -- Patrick K. O'Brien Orbtech ----------------------------------------------- "Your source for Python programming expertise." ----------------------------------------------- Web: http://www.orbtech.com/web/pobrien/ Blog: http://www.orbtech.com/blog/pobrien/ Wiki: http://www.orbtech.com/wiki/PatrickOBrien ----------------------------------------------- From glingl@aon.at Mon Sep 2 18:19:29 2002 From: glingl@aon.at (Gregor Lingl) Date: Mon, 02 Sep 2002 19:19:29 +0200 Subject: [Idle-dev] Re: [Tutor] Help concerning raw_input urgently needed! References: <20020901225120.D9FA19370B@server2.fastmail.fm> <5.1.0.14.0.20020902101532.02b438b8@www.thinkware.se> <200209021409.g82E9uZ30689@pcp02138704pcs.reston01.va.comcast.net> Message-ID: <3D739DA1.5050106@aon.at> Guido van Rossum schrieb: >>I think the problem is that Tcl/Tk use Unicode these days, >>and Python defaults to ISO8859-1. >> >> > >That's not true. > > > >>Thus your umlaut is ok for raw_input in python proper. In IDLE, the >>characters are recieved by Tk, and translated from Unicode. That >>fails on any non-ASCII value, since these are ambiguous unless a >>code page is supplied. >> >> > >Try the IDLE from current CVS. AFAIK the Unicode issues have been >fixed there. > >--Guido van Rossum (home page: http://www.python.org/~guido/) > > No, the problem addressed has not been fixed there. I don't know, if Unicode issues are involved, but anyway we find: Python 2.2.1 (#34, Apr 9 2002, 19:34:33) [MSC 32 bit (Intel)] on win32 Type "copyright", "credits" or "license" for more information. IDLE Fork 0.8 -- press F1 for help >>> a = raw_input("Hä? ") Hä? Tschüs Traceback (most recent call last): File "", line 1, in ? a = raw_input("Hä? ") TypeError: object.readline() returned non-string >>> Gregor From guido@python.org Mon Sep 2 20:02:47 2002 From: guido@python.org (Guido van Rossum) Date: Mon, 02 Sep 2002 15:02:47 -0400 Subject: [Idle-dev] Re: [Tutor] Help concerning raw_input urgently needed! In-Reply-To: Your message of "Mon, 02 Sep 2002 09:30:20 CDT." References: Message-ID: <200209021902.g82J2lN31121@pcp02138704pcs.reston01.va.comcast.net> > [Guido van Rossum] > > > > Try the IDLE from current CVS. AFAIK the Unicode issues have been > > fixed there. > > I just updated from CVS and gave it a try. :-( > > Python 2.2.1 (#34, Apr 9 2002, 19:34:33) [MSC 32 bit (Intel)] on win32 > Type "copyright", "credits" or "license" for more information. > GRPC IDLE Fork 0.8.2 > >>> a = raw_input("Hä? ") > UnicodeError: ASCII encoding error: ordinal not in range(128) Sorry, that's the idlefork IDLE. I meant the core Python CVS. --Guido van Rossum (home page: http://www.python.org/~guido/) From kbk@users.sourceforge.net Mon Sep 2 22:29:42 2002 From: kbk@users.sourceforge.net (Kurt B. Kaiser) Date: Mon, 02 Sep 2002 14:29:42 -0700 Subject: [Idle-dev] CVS: idle OutputWindow.py,1.4,1.5 Message-ID: Update of /cvsroot/idlefork/idle In directory usw-pr-cvs1:/tmp/cvs-serv15976 Modified Files: OutputWindow.py Log Message: (Re)Apply Sourceforge Python patch 520483, Sourceforge Idlefork patch 521908 (again) to MAIN The patch applied by Steven was inadvertently reverted during the transition to GRPC. Python 2.3a0 (#3, May 8 2002, 23:37:01) [GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2 Type "copyright", "credits" or "license" for more information. GRPC IDLE Fork 0.8.2 >>> print u'\xbfQu\xe9 pas\xf3?' ¿Qué pasó? Modified Files: OutputWindow.py Index: OutputWindow.py =================================================================== RCS file: /cvsroot/idlefork/idle/OutputWindow.py,v retrieving revision 1.4 retrieving revision 1.5 diff -C2 -r1.4 -r1.5 *** OutputWindow.py 12 Jun 2002 03:28:57 -0000 1.4 --- OutputWindow.py 2 Sep 2002 21:29:40 -0000 1.5 *************** *** 35,39 **** def write(self, s, tags=(), mark="insert"): ! self.text.insert(mark, str(s), tags) self.text.see(mark) self.text.update() --- 35,39 ---- def write(self, s, tags=(), mark="insert"): ! self.text.insert(mark, s, tags) self.text.see(mark) self.text.update() From kbk@shore.net Mon Sep 2 22:35:58 2002 From: kbk@shore.net (Kurt B. Kaiser) Date: 02 Sep 2002 17:35:58 -0400 Subject: [Idle-dev] Re: [Tutor] Help concerning raw_input urgently needed! In-Reply-To: References: Message-ID: "Patrick K. O'Brien" writes: > [Guido van Rossum] > > > > Try the IDLE from current CVS. AFAIK the Unicode issues have been > > fixed there. >=20 > I just updated from CVS and gave it a try. :-( >=20 > Python 2.2.1 (#34, Apr 9 2002, 19:34:33) [MSC 32 bit (Intel)] on win32 > Type "copyright", "credits" or "license" for more information. > GRPC IDLE Fork 0.8.2 > >>> a =3D raw_input("H=E4? ") > UnicodeError: ASCII encoding error: ordinal not in range(128) I have reapplied the patch kindly submitted by Jason Orendorff (jorend). It was inadvertently reverted in MAIN when I moved to GvR version of=20 RPC. DS_RPC_BRANCH is OK, fixed earlier by S. Gava. Python 2.3a0 (#3, May 8 2002, 23:37:01)=20 [GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2 Type "copyright", "credits" or "license" for more information. GRPC IDLE Fork 0.8.2 >>> print u'\xbfQu\xe9 pas\xf3?' =C2=BFQu=C3=A9 pas=C3=B3? =20 KBK From kbk@shore.net Mon Sep 2 22:47:55 2002 From: kbk@shore.net (Kurt B. Kaiser) Date: 02 Sep 2002 17:47:55 -0400 Subject: [Idle-dev] DS_RPC_BRANCH Message-ID: I was unable to test the Unicode fix in the branch (though I assume it works); the branch is broken for me because loader.py, which is apparently necessary for DS_RPC to function, was removed and also because the merge of Autoindent.py into EditorWindow.py needs some work. (AutoIndent is still a required extension in PyShell.py, but the module has been removed.) KBK From elguavas@python.net Tue Sep 3 00:46:51 2002 From: elguavas@python.net (Stephen M. Gava) Date: 03 Sep 2002 09:46:51 +1000 Subject: [Idle-dev] DS_RPC_BRANCH In-Reply-To: References: Message-ID: <1031010413.535.24.camel@oberon> On Tue, 2002-09-03 at 07:47, Kurt B. Kaiser wrote: > I was unable to test the Unicode fix in the branch (though I assume it > works); the branch is broken for me because loader.py, which is > apparently necessary for DS_RPC to function, was removed and also > because the merge of Autoindent.py into EditorWindow.py needs some > work. (AutoIndent is still a required extension in PyShell.py, but > the module has been removed.) Kurt, please try this again on a clean checkout of only DS_RPC_BRANCH (cvs up -r DS_RPC_BRANCH). I am still stuck only working on this branch and I have no such problems here. If there are problems, this whole situation only goes to reinforce what I've been saying about how we need to fold the branch back into main now and continue all development there. The fact is, if we were both working on the same branch (or the trunk) then problems of all these kinds wouldn't arise; any breakages would be detected in a much more timely fashion because we'd both be working on and testing the same code, and there would be no patches getting lost and no confusion for our users about exactly what they should check out if they want to use cvs. These kinds of problems were exactly why I argued against branching the development effort (of course just tagging cvs itself causes no problem) in the first place. When you and Guido convinced me to have work proceed on two branches simultaneously in the first place it was with a couple of provisos; one was that you volunteered to make regular (weekly or fortnightly) merges of DS_RPC_BRANCH back to main, and the other was that it would only be a short term temporary situation and that all development would soon be able to continue on main. So I'll repeat my question of a couple of weeks ago again, would you be able do a merge soon, please, so that we can get things back on track? I realize the time you have available has all been taken up working on the rpc stuff so you've had no time to do a merge yet, but really, I think this is a priority. Thanks, Stephen. -- Stephen M. Gava http://python.net/crew/elguavas IDLEfork http://idlefork.sourceforge.net "just like IDLE, only crunchy" From elguavas@python.net Tue Sep 3 01:49:35 2002 From: elguavas@python.net (Stephen M. Gava) Date: 03 Sep 2002 10:49:35 +1000 Subject: [Idle-dev] DS_RPC_BRANCH In-Reply-To: <1031010413.535.24.camel@oberon> References: <1031010413.535.24.camel@oberon> Message-ID: <1031014176.726.29.camel@oberon> On Tue, 2002-09-03 at 09:46, Stephen M. Gava wrote: > please try this again on a clean checkout of only DS_RPC_BRANCH (cvs up > -r DS_RPC_BRANCH). I am still stuck only working on this branch and I > have no such problems here. Oh, and also there have been config file changes, so if you have a ~/.idlerc you should wipe it... -- Stephen M. Gava http://python.net/crew/elguavas IDLEfork http://idlefork.sourceforge.net "just like IDLE, only crunchy" From kbk@shore.net Tue Sep 3 02:56:11 2002 From: kbk@shore.net (Kurt B. Kaiser) Date: 02 Sep 2002 21:56:11 -0400 Subject: [Idle-dev] DS_RPC_BRANCH In-Reply-To: <1031010413.535.24.camel@oberon> References: <1031010413.535.24.camel@oberon> Message-ID: "Stephen M. Gava" writes: > On Tue, 2002-09-03 at 07:47, Kurt B. Kaiser wrote: > > I was unable to test the Unicode fix in the branch (though I assume it > > works); the branch is broken for me because loader.py, which is > > apparently necessary for DS_RPC to function, was removed and also > > because the merge of Autoindent.py into EditorWindow.py needs some > > work. (AutoIndent is still a required extension in PyShell.py, but > > the module has been removed.) > > Kurt, > please try this again on a clean checkout of only DS_RPC_BRANCH (cvs up > -r DS_RPC_BRANCH). I am still stuck only working on this branch and I > have no such problems here. I did a clean checkout into a sandbox, not just an update. The error message when starting Idle is [kbk@float ~/proj/sandbox/idlefork]$ python idle.py Failed to load extension 'ExecBinding' Traceback (most recent call last): File "EditorWindow.py", line 691, in load_standard_extensions self.load_extension(name) File "EditorWindow.py", line 701, in load_extension mod = __import__(name, globals(), locals(), []) File "/home/kbk/proj/sandbox/idlefork/ExecBinding.py", line 30, in ? load_py = spawn.hardpath( imp.find_module("loader")[1] ) ImportError: No module named loader If I add loader.py back to the sandbox, the next error I get is PyShell.py complaining at line 318. The code appears to require the AutoIndent module. I notice some CVS problems when updating between MAIN and DS_RPC_BRANCH. The problems are related to files deleted into the Attic but they don't properly disappear from the local working directory. Is loader.py actually gone from your working directory? That's why I did the clean checkout. Regards, KBK From kbk@shore.net Tue Sep 3 04:09:58 2002 From: kbk@shore.net (Kurt B. Kaiser) Date: 02 Sep 2002 23:09:58 -0400 Subject: [Idle-dev] Re: [Tutor] Help concerning raw_input urgently needed! In-Reply-To: <3D739DA1.5050106@aon.at> References: <20020901225120.D9FA19370B@server2.fastmail.fm> <5.1.0.14.0.20020902101532.02b438b8@www.thinkware.se> <200209021409.g82E9uZ30689@pcp02138704pcs.reston01.va.comcast.net> <3D739DA1.5050106@aon.at> Message-ID: Gregor Lingl writes: > IDLE Fork 0.8 -- press F1 for help This version predates the patch, which was applied 23Feb2002. KBK From elguavas@users.sourceforge.net Tue Sep 3 04:39:11 2002 From: elguavas@users.sourceforge.net (Stephen M. Gava) Date: Mon, 02 Sep 2002 20:39:11 -0700 Subject: [Idle-dev] CVS: idle loader.py,1.2.2.1,1.2.2.2 Message-ID: Update of /cvsroot/idlefork/idle In directory usw-pr-cvs1:/tmp/cvs-serv2373 Added Files: Tag: DS_RPC_BRANCH loader.py Log Message: resurrected from the attic, was required after all From elguavas@python.net Tue Sep 3 04:47:34 2002 From: elguavas@python.net (Stephen M. Gava) Date: 03 Sep 2002 13:47:34 +1000 Subject: [Idle-dev] DS_RPC_BRANCH In-Reply-To: References: <1031010413.535.24.camel@oberon> Message-ID: <1031024854.23079.6.camel@oberon> Kurt B. Kaiser wrote: > I did a clean checkout into a sandbox, not just an update. The error > message when starting Idle is Hmm, you are right. It seems my search for dependencies on loader.py was deficient. I've restored it from the attic. > Is loader.py actually gone from your working directory? It was, but I still had a loader.pyc ...*sigh* > If I add loader.py back to the sandbox, the next error I get is > PyShell.py complaining at line 318. The code appears to require the > AutoIndent module. However with loader.py back in my sandbox (and *.pyc removed :) I still don't get this problem at all. I will look into this further. Did you wipe your old config directory? Stephen. -- Stephen M. Gava http://python.net/crew/elguavas IDLEfork http://idlefork.sourceforge.net "just like IDLE, only crunchy" From elguavas@python.net Tue Sep 3 05:02:46 2002 From: elguavas@python.net (Stephen M. Gava) Date: 03 Sep 2002 14:02:46 +1000 Subject: [Idle-dev] DS_RPC_BRANCH In-Reply-To: <1031024854.23079.6.camel@oberon> References: <1031010413.535.24.camel@oberon> <1031024854.23079.6.camel@oberon> Message-ID: <1031025767.23079.12.camel@oberon> Stephen M. Gava wrote: > However with loader.py back in my sandbox (and *.pyc removed :) I still > don't get this problem at all. I will look into this further. Did you > wipe your old config directory? Ok, I just did a new checkout (cvs co -r DS_RPC_BRANCH idle) into a squeaky clean new sandbox, and I don't get any errors on startup relating to AutoIndent (in fact no errors at all). Strange. Can you try again and send me the traceback? Stephen. -- Stephen M. Gava http://python.net/crew/elguavas IDLEfork http://idlefork.sourceforge.net "just like IDLE, only crunchy" From elguavas@python.net Tue Sep 3 05:16:44 2002 From: elguavas@python.net (Stephen M. Gava) Date: 03 Sep 2002 14:16:44 +1000 Subject: [Idle-dev] DS_RPC_BRANCH In-Reply-To: <1031025767.23079.12.camel@oberon> References: <1031010413.535.24.camel@oberon> <1031024854.23079.6.camel@oberon> <1031025767.23079.12.camel@oberon> Message-ID: <1031026604.23079.20.camel@oberon> Stephen M. Gava wrote: > Strange. Can you try > again and send me the traceback? Ok I've just found it. It doesn't happen for me on startup (which should by default open an editor window), but it does when I open a shell window. Seems that although AutoIndent used to be an "extension" PyShell has a lot of dirty hard coded stuff relating to it. Grrr. I'll get on to trying to sort that out as soon as I can. Cheers, Stephen. -- Stephen M. Gava http://python.net/crew/elguavas IDLEfork http://idlefork.sourceforge.net "just like IDLE, only crunchy" From kbk@shore.net Tue Sep 3 05:44:28 2002 From: kbk@shore.net (Kurt B. Kaiser) Date: 03 Sep 2002 00:44:28 -0400 Subject: [Idle-dev] DS_RPC_BRANCH In-Reply-To: <1031024854.23079.6.camel@oberon> References: <1031010413.535.24.camel@oberon> <1031024854.23079.6.camel@oberon> Message-ID: "Stephen M. Gava" writes: > It was, but I still had a loader.pyc ...*sigh* I didn't fall afoul of that one, though I should have...gotta remember that :) rm *.pyc for testing if any files are deleted!! But I was having some kind of weird cvs problem where (after the first error and added loader.py manually) when I updated back and forth between the two branches cvs wouldn't remove loader.py even though it was supposed to be in the Attic on the DS_RPC_BRANCH. When I did a stat cvs claimed things were ok, a copy in the local directory and the same rev in the repository Attic :-( rm'ing loader.py didn't help, it would just get put back in on the next update! It was like my local CVS directory was screwed. I haven't tried to duplicate this yet, just nuked the whole sandbox and checked out a new one. Regards, KBK From kbk@shore.net Tue Sep 3 23:00:57 2002 From: kbk@shore.net (Kurt B. Kaiser) Date: 03 Sep 2002 18:00:57 -0400 Subject: [Idle-dev] DS_RPC_BRANCH References: <1031010413.535.24.camel@oberon> Message-ID: "Stephen M. Gava" writes: > On Tue, 2002-09-03 at 07:47, Kurt B. Kaiser wrote: > > I was unable to test the Unicode fix in the branch (though I assume it > > works); the branch is broken for me because loader.py, which is > > apparently necessary for DS_RPC to function, was removed and also > > because the merge of Autoindent.py into EditorWindow.py needs some > > work. (AutoIndent is still a required extension in PyShell.py, but > > the module has been removed.) [...] > If there are problems, this whole situation only goes to reinforce what > I've been saying about how we need to fold the branch back into main now > and continue all development there. The fact is, if we were both working > on the same branch (or the trunk) then problems of all these kinds > wouldn't arise; any breakages would be detected in a much more timely > fashion because we'd both be working on and testing the same code, We could not reasonably both work on the same branch, but that phase is ending. See below. That doesn't mean we don't test each other's code, though, at least occasionally. > and there would be no patches getting lost If you are talking about the Unicode patch, it didn't get lost. I wiped it out by accident when I ripped out the DS_RPC code in OutputWindow.py. Patrick O'Brien was kind enough to test GRPC and post the bug. > and no confusion for our users about exactly what they should check > out if they want to use cvs. These kinds of problems were exactly > why I argued against branching the development effort (of course > just tagging cvs itself causes no problem) in the first place. It is common practice to split off a branch when 1. Major changes are contemplated which should be isolated until the design and the code are stable. Then there's a merge. RSN :) 2. A release is made and a bugfix branch is started which will get only critical fixes. Python and many other OS projects do this often. Most users have no trouble dealing with it, especially if a packaged release of the branch is made periodically. Eventually the branch is left behind. I continue to think we should have a final release of the DS RPC version of Idlefork. However, this is worth doing only if Sherwood et. al. are interested in that happening. (although I'd be interested in one merely for closure's sake :) In the course of working on GRPC I've come across couple of apparent bugs which should be investigated, but only a couple. It seems pretty solid, and I would think they would want to avail themselves of all the good work you've been putting into it over the past year. > When you and Guido convinced me to have work proceed on two branches > simultaneously in the first place it was with a couple of provisos; > one was that you volunteered to make regular (weekly or fortnightly) > merges of DS_RPC_BRANCH back to main, and the other was that it > would only be a short term temporary situation and that all > development would soon be able to continue on main. You seem to be telling me to hurry up and finish the conversion to GRPC so that you don't have to feel slighted by being "stuck" on a branch that doesn't have the tag "MAIN" :) Hey, it's only a name! It's not practical to do the kind of work I'm doing on the same branch with other development. The changes I made were drastic and you couldn't work on your tasks with me continually pulling the rug out from under you by changing the whole design and internal code structure. And I didn't want to tiptoe about worrying about screwing you up. So the only question was, which branch is called "MAIN"? And the reasonable answer was, the basic rpc design we were going to stay with long term, because that puts DS_RPC in a terminating bugfix side branch. It's _much_ easier to merge you to me than vice-versa! There is no reason why you shouldn't charge ahead on DS_RPC_BRANCH. I'm not afraid of merges! But I'm almost done (I hope) with the rpc conversion. The restart code is running. One of the things I have yet to do is reload the subprocess debugger breakpoints during the restart. But the overall structure has settled down and the code in CVS is quite usable. (Has been all along from a user point of view, actually. I hope people will try it and give me feedback.) Soon you can switch over to MAIN without having to worry that the whole design changed overnight (again) and your concept of a major portion of the codebase is (once more) obsolete. > So I'll repeat my question of a couple of weeks ago again, would you > be able do a merge soon, please, so that we can get things back on > track? I realize the time you have available has all been taken up > working on the rpc stuff so you've had no time to do a merge yet, > but really, I think this is a priority. There is not all that much to merge, because some of the stripping you are doing tracks what I did. As a matter of fact, I was looking into a merge, and I ran into the issues discussed in my previous post. Once I get DS_RPC running in my sandbox, I'll run my little test suite on it and then do a merge to MAIN right away so we can be "on track". Regards, KBK From basherwo@unity.ncsu.edu Tue Sep 3 23:12:41 2002 From: basherwo@unity.ncsu.edu (Bruce Sherwood) Date: Tue, 3 Sep 2002 18:12:41 -0400 Subject: [Idle-dev] DS_RPC_BRANCH References: <1031010413.535.24.camel@oberon> Message-ID: <006f01c25397$05a67f80$e5770198@muon> Since my name appears in this note, I'll say that I'm certainly very interested in bundling a spiffy new version of IDLE with VPython. I've been consumed with a move from Carnegie Mellon to North Carolina State University, so I haven't attempted to run a recent version of idlefork, due to my (mis?)perception that there really has never been something one might call a "release". Once there is such a thing, I'll certainly try it myself and consult with you developers on whether it's ready for prime time with novice freshmen in a physics course. Bruce Sherwood ----- Original Message ----- From: "Kurt B. Kaiser" To: Sent: Tuesday, September 03, 2002 6:00 PM Subject: Re: [Idle-dev] DS_RPC_BRANCH > "Stephen M. Gava" writes: > > > On Tue, 2002-09-03 at 07:47, Kurt B. Kaiser wrote: > > > I was unable to test the Unicode fix in the branch (though I assume it > > > works); the branch is broken for me because loader.py, which is > > > apparently necessary for DS_RPC to function, was removed and also > > > because the merge of Autoindent.py into EditorWindow.py needs some > > > work. (AutoIndent is still a required extension in PyShell.py, but > > > the module has been removed.) > > [...] > > > If there are problems, this whole situation only goes to reinforce what > > I've been saying about how we need to fold the branch back into main now > > and continue all development there. The fact is, if we were both working > > on the same branch (or the trunk) then problems of all these kinds > > wouldn't arise; any breakages would be detected in a much more timely > > fashion because we'd both be working on and testing the same code, > > We could not reasonably both work on the same branch, but that phase > is ending. See below. That doesn't mean we don't test each other's > code, though, at least occasionally. > > > and there would be no patches getting lost > > If you are talking about the Unicode patch, it didn't get lost. I > wiped it out by accident when I ripped out the DS_RPC code in > OutputWindow.py. Patrick O'Brien was kind enough to test GRPC and > post the bug. > > > and no confusion for our users about exactly what they should check > > out if they want to use cvs. These kinds of problems were exactly > > why I argued against branching the development effort (of course > > just tagging cvs itself causes no problem) in the first place. > > It is common practice to split off a branch when > > 1. Major changes are contemplated which should be isolated until the > design and the code are stable. Then there's a merge. RSN :) > > 2. A release is made and a bugfix branch is started which will get > only critical fixes. Python and many other OS projects do this > often. Most users have no trouble dealing with it, especially if > a packaged release of the branch is made periodically. Eventually > the branch is left behind. > > I continue to think we should have a final release of the DS RPC > version of Idlefork. However, this is worth doing only if Sherwood > et. al. are interested in that happening. (although I'd be > interested in one merely for closure's sake :) In the course of > working on GRPC I've come across couple of apparent bugs which > should be investigated, but only a couple. It seems pretty solid, > and I would think they would want to avail themselves of all the > good work you've been putting into it over the past year. > > > When you and Guido convinced me to have work proceed on two branches > > simultaneously in the first place it was with a couple of provisos; > > one was that you volunteered to make regular (weekly or fortnightly) > > merges of DS_RPC_BRANCH back to main, and the other was that it > > would only be a short term temporary situation and that all > > development would soon be able to continue on main. > > You seem to be telling me to hurry up and finish the conversion to > GRPC so that you don't have to feel slighted by being "stuck" on a > branch that doesn't have the tag "MAIN" :) Hey, it's only a name! > > It's not practical to do the kind of work I'm doing on the same > branch with other development. The changes I made were drastic and > you couldn't work on your tasks with me continually pulling the rug > out from under you by changing the whole design and internal code > structure. And I didn't want to tiptoe about worrying about screwing > you up. So the only question was, which branch is called "MAIN"? And > the reasonable answer was, the basic rpc design we were going to stay > with long term, because that puts DS_RPC in a terminating bugfix > side branch. It's _much_ easier to merge you to me than vice-versa! > > There is no reason why you shouldn't charge ahead on DS_RPC_BRANCH. > I'm not afraid of merges! > > But I'm almost done (I hope) with the rpc conversion. The restart > code is running. One of the things I have yet to do is reload the > subprocess debugger breakpoints during the restart. But the overall > structure has settled down and the code in CVS is quite usable. (Has > been all along from a user point of view, actually. I hope people > will try it and give me feedback.) > > Soon you can switch over to MAIN without having to worry that the > whole design changed overnight (again) and your concept of a major > portion of the codebase is (once more) obsolete. > > > So I'll repeat my question of a couple of weeks ago again, would you > > be able do a merge soon, please, so that we can get things back on > > track? I realize the time you have available has all been taken up > > working on the rpc stuff so you've had no time to do a merge yet, > > but really, I think this is a priority. > > There is not all that much to merge, because some of the stripping you > are doing tracks what I did. As a matter of fact, I was looking into > a merge, and I ran into the issues discussed in my previous post. > > Once I get DS_RPC running in my sandbox, I'll run my little test suite > on it and then do a merge to MAIN right away so we can be "on track". > > Regards, KBK > > > _______________________________________________ > IDLE-dev mailing list > IDLE-dev@python.org > http://mail.python.org/mailman/listinfo/idle-dev > From kbk@shore.net Wed Sep 4 01:17:27 2002 From: kbk@shore.net (Kurt B. Kaiser) Date: 03 Sep 2002 20:17:27 -0400 Subject: [Idle-dev] DS_RPC_BRANCH References: <1031010413.535.24.camel@oberon> <006f01c25397$05a67f80$e5770198@muon> Message-ID: "Bruce Sherwood" writes: > Since my name appears in this note, I'll say that I'm certainly very > interested in bundling a spiffy new version of IDLE with VPython. I've been > consumed with a move from Carnegie Mellon to North Carolina State > University, so I haven't attempted to run a recent version of idlefork, due > to my (mis?)perception that there really has never been something one might > call a "release". Once there is such a thing, I'll certainly try it myself > and consult with you developers on whether it's ready for prime time with > novice freshmen in a physics course. I was hoping you would pop up! As you're aware, recently I've been converting the code to use Guido's RPC. A major reason for doing that instead of further developing David Scherer's RPC was that the GvR code implemented a split version of the Idle debugger and allowed inspection of the environment in a Python shell following a Run. >From the user's point of view, the main difference is the output of a Run appears in a shell window instead of in a separate output window. But as in VP Idle, a fresh environment is created every time Run/F5 is activated. Steven Gava has been working hard over the past year to improve the configurability of VP Idle. The results of his work are in the DS_RPC_BRANCH, and also in the MAIN branch. The first question is, are you interested in a final release of the VP Idle line of development so you can make use of that work? Another question: at what point might you jump to the new GRPC version? What would we need to do to make it attractive to you? Are you comfortable downloading from cvs or should we package up releases for you? Regards, KBK From elguavas@python.net Wed Sep 4 02:04:47 2002 From: elguavas@python.net (Stephen M. Gava) Date: 04 Sep 2002 11:04:47 +1000 Subject: [Idle-dev] DS_RPC_BRANCH In-Reply-To: References: <1031010413.535.24.camel@oberon> Message-ID: <1031101488.538.99.camel@oberon> On Wed, 2002-09-04 at 08:00, Kurt B. Kaiser wrote: > We could not reasonably both work on the same branch, but that phase > is ending. Well, from watching the state of both branches, I think that in reality, with just a couple of short waits on my part, we could have coordinated it fairly easily. *shrug* > See below. That doesn't mean we don't test each other's > code, though, at least occasionally. Sure, but it means maintaining two checkouts and spending time only testing. This is the exactly kind of makework I had hoped to avoid in the actual case, of two part time developers. > > and there would be no patches getting lost > > If you are talking about the Unicode patch, it didn't get lost. I > wiped it out by accident when I ripped out the DS_RPC code in > OutputWindow.py. Patrick O'Brien was kind enough to test GRPC and > post the bug. Well, I guess that's just semantics. ;^) I call that "getting lost" at least temporarily, you call it "being wiped by accident then replaced". The net result for cvs users was that the patch was lost from recent checkouts. > It is common practice to split off a branch when I'm perfectly aware that it's "common practice"; I just don't happen to believe that it was the best thing for us to have done in our actual case here. I was worried that it might cause more problems for us than it would solve, and I think it has. > I continue to think we should have a final release of the DS RPC > version of Idlefork. Please re-read my earlier detailed response to this suggestion. I guess it sounds pretty simple to just pop out a release, but actually it's a lot of work. Again I think we must avoid nice sounding in theory makework that steals what little time we have between us away from what we actually need to be focusing our limited energies on: getting out some tarballs of 0.9x with all the new stuff in for people to test. Let me try and explain myself. My focus in all of this has not been on the most theoretically perfect way of proceeding, it has been purely on managing a project with very limited resources in such a way that I hope we will achieve the main desired result. Sometimes that approach does not equal doing things the most theoretically perfect way. If you are unhappy with my attempts to carry out my role with the project, which is not only developer but manger and coordinator, then I am happy to drop back to just being a developer if you want to take over that coordinating role and move things in a different direction, honestly, I could well do without the extra grief. > You seem to be telling me to hurry up and finish the conversion to > GRPC so that you don't have to feel slighted by being "stuck" on a > branch that doesn't have the tag "MAIN" :) Hey, it's only a name! C'mon Kurt, why would I care about that? Man. My concern, which I've restated several times, is that splitting active development over two branches will be inefficient and not really in the best interests of the project. I think that has proven to be the case. I reiterate that the idea of tagging a branch with the old rpc code was a good one, but I don't think dividing our developer effort was. > It's not practical to do the kind of work I'm doing on the same > branch with other development. The changes I made were drastic and > you couldn't work on your tasks with me continually pulling the rug > out from under you by changing the whole design and internal code > structure. And I didn't want to tiptoe about worrying about screwing > you up. Well as I've said already, this was why I agreed on two active development streams, but only in the short term. From watching the state of the checkins I feel that that stage passed quite early on, early enough in fact for my recent work to have been happily on the same branch. In fact I have a backlog of python idle patches to move over now as well that should not be applied on the branch but also should not be applied to the trunk before we merge back. So again, I think that if the splitting of the active development effort had been much shorter, the problems possibly caused would have been far outweighed by the problems actually solved. Of course what's done is done and now we make the best of it, but in retrospect I think that I should have just waited a little while a couple of times for the dust to settle and then continued working on the same branch as you, I believe the economies of scale were in favour of this approach in the realities of our project. You don't, so there you go. > There is no reason why you shouldn't charge ahead on DS_RPC_BRANCH. > I'm not afraid of merges! The bigger they are the more time they waste. I'm not able to be so cavalier with my limited free time and energies. I think the best merge is no merge required. > But I'm almost done (I hope) with the rpc conversion. The restart > code is running. One of the things I have yet to do is reload the > subprocess debugger breakpoints during the restart. But the overall > structure has settled down and the code in CVS is quite usable. (Has > been all along from a user point of view, actually. I hope people > will try it and give me feedback.) That's great. I've been following your work in commits and messages here and it's really terrific. The quality of the future idle will owe you a great debt. I'm sorry but I honestly haven't had the time to maintain a separate checkout and do testing-only work on your branch as well. Like the rest of the new stuff, your code will get the lion's share of it's testing when we can include it in some tarball releases. > There is not all that much to merge, because some of the stripping you > are doing tracks what I did. I'm glad to hear that. Of course I wait til you are ready to spend time on the merge. If I unintentionally sounded a little peeved in my last message about "are we able to do this soon" it was probably because I got no answer on that the first time, undoubtedly because you have been so busy, so apologies for that. > As a matter of fact, I was looking into > a merge, and I ran into the issues discussed in my previous post. > > Once I get DS_RPC running in my sandbox, I'll run my little test suite > on it and then do a merge to MAIN right away so we can be "on track". Yes, you may want to wait until I have a chance to sort out PyShell's dirty AutoIndent code. I guess it doesn't matter though, as long as those fixes are also propagated over to DS_RPC_BRANCH so that I'm not knowingly leaving any major breakage there. Ciao, Stephen. -- Stephen M. Gava http://python.net/crew/elguavas IDLEfork http://idlefork.sourceforge.net "just like IDLE, only crunchy" From elguavas@python.net Wed Sep 4 02:27:07 2002 From: elguavas@python.net (Stephen M. Gava) Date: 04 Sep 2002 11:27:07 +1000 Subject: [Idle-dev] DS_RPC_BRANCH In-Reply-To: <006f01c25397$05a67f80$e5770198@muon> References: <1031010413.535.24.camel@oberon> <006f01c25397$05a67f80$e5770198@muon> Message-ID: <1031102828.538.119.camel@oberon> On Wed, 2002-09-04 at 08:12, Bruce Sherwood wrote: > Since my name appears in this note, I'll say that I'm certainly very > interested in bundling a spiffy new version of IDLE with VPython. I've been > consumed with a move from Carnegie Mellon to North Carolina State > University, so I haven't attempted to run a recent version of idlefork, due > to my (mis?)perception that there really has never been something one might > call a "release". Hi Bruce. No, there hasn't been any official release of any of the new code yet, it only exits in cvs. > Once there is such a thing, I'll certainly try it myself > and consult with you developers on whether it's ready for prime time with > novice freshmen in a physics course. That would be great. When we've completed some soon to be undertaken shuffling around in cvs and finished off a couple more items on our todo list we're aiming at some testing releases for all the new stuff, hopefully leading up to some beta releases in the not too distant future at which point idlefork may be in a state you'd want to consider doing a build for vpython from. As you know the ultimate aim is to have all this new stuff in python idle, so that with just a few configuration changes the one version of idle should be suitable for both vpython and python itself. Ciao, Stephen. -- Stephen M. Gava http://python.net/crew/elguavas IDLEfork http://idlefork.sourceforge.net "just like IDLE, only crunchy" From basherwo@unity.ncsu.edu Wed Sep 4 02:40:12 2002 From: basherwo@unity.ncsu.edu (Bruce Sherwood) Date: Tue, 3 Sep 2002 21:40:12 -0400 Subject: [Idle-dev] DS_RPC_BRANCH References: <1031010413.535.24.camel@oberon> <006f01c25397$05a67f80$e5770198@muon> Message-ID: <002601c253b4$02d44680$6801a8c0@hyperon> I would much prefer that there be a "release" rather than trying to figure out what to do with CVS, a system I use but very inexpertly. A release would also let some other VPython users who know even less than I or nothing at all about CVS to try out what the idlefork developers have been doing. And frankly the existence of a "release" even if labeled "experimental" or "draft" or whatever sends the rest of us a signal that it is time to pay serious attention and try things out. By the way, I think that I'm an easy sell. It sounds like a win to have the output window be interactive, and it most certainly is a win to be able to configure things. As I once mentioned in this forum, I bounced off trying to configure IDLE on Linux to have the key bindings I'm used to on other platforms (e.g. CTRL-C for copy rather than the Emacs-style multiple keypresses). And as a minor matter, when I'm making presentations I have to change two config files, then restart IDLE to get a large font. Bruce Sherwood From elguavas@python.net Wed Sep 4 02:48:57 2002 From: elguavas@python.net (Stephen M. Gava) Date: 04 Sep 2002 11:48:57 +1000 Subject: [Idle-dev] DS_RPC_BRANCH In-Reply-To: <002601c253b4$02d44680$6801a8c0@hyperon> References: <1031010413.535.24.camel@oberon> <006f01c25397$05a67f80$e5770198@muon> <002601c253b4$02d44680$6801a8c0@hyperon> Message-ID: <1031104138.1271.127.camel@oberon> Hi again Bruce. I think our messages just "crossed". My most recent post to the list, which appeared in my inbox about the same time as this message of yours, should address your concerns about what is a "release" or not. The quick answers are yes, the actual releases will be official tarballs and no, I don't expect you to have to be be messing around with cvs or code that is still only in early testing stages. Cheers, Stephen. On Wed, 2002-09-04 at 11:40, Bruce Sherwood wrote: > I would much prefer that there be a "release" rather than trying to figure > out what to do with CVS, a system I use but very inexpertly. A release would > also let some other VPython users who know even less than I or nothing at > all about CVS to try out what the idlefork developers have been doing. And > frankly the existence of a "release" even if labeled "experimental" or > "draft" or whatever sends the rest of us a signal that it is time to pay > serious attention and try things out. > > By the way, I think that I'm an easy sell. It sounds like a win to have the > output window be interactive, and it most certainly is a win to be able to > configure things. As I once mentioned in this forum, I bounced off trying to > configure IDLE on Linux to have the key bindings I'm used to on other > platforms (e.g. CTRL-C for copy rather than the Emacs-style multiple > keypresses). And as a minor matter, when I'm making presentations I have to > change two config files, then restart IDLE to get a large font. > > Bruce Sherwood > > > > _______________________________________________ > IDLE-dev mailing list > IDLE-dev@python.org > http://mail.python.org/mailman/listinfo/idle-dev -- Stephen M. Gava http://python.net/crew/elguavas IDLEfork http://idlefork.sourceforge.net "just like IDLE, only crunchy" From kbk@shore.net Wed Sep 4 03:51:56 2002 From: kbk@shore.net (Kurt B. Kaiser) Date: 03 Sep 2002 22:51:56 -0400 Subject: [Idle-dev] DS_RPC_BRANCH References: <1031010413.535.24.camel@oberon> <1031101488.538.99.camel@oberon> Message-ID: "Stephen M. Gava" writes: > On Wed, 2002-09-04 at 08:00, Kurt B. Kaiser wrote: [...] > > Stephen M. Gava wrote: > > > and there would be no patches getting lost > > > > If you are talking about the Unicode patch, it didn't get lost. I > > wiped it out by accident when I ripped out the DS_RPC code in > > OutputWindow.py. Patrick O'Brien was kind enough to test GRPC and > > post the bug. > > Well, I guess that's just semantics. ;^) I call that "getting lost" at > least temporarily, you call it "being wiped by accident then replaced". > The net result for cvs users was that the patch was lost from recent > checkouts. I would have croaked it even if we were working on one branch. [...] > > I continue to think we should have a final release of the DS RPC > > version of Idlefork. > > Please re-read my earlier detailed response to this suggestion. I guess > it sounds pretty simple to just pop out a release, but actually it's a > lot of work. I'll be happy to do it. Especially if the VP guys would like one; we haven't had one for a year. > Again I think we must avoid nice sounding in theory makework that > steals what little time we have between us away from what we > actually need to be focusing our limited energies on: getting out > some tarballs of 0.9x with all the new stuff in for people to test. > Let me try and explain myself. My focus in all of this has not been > on the most theoretically perfect way of proceeding, it has been > purely on managing a project with very limited resources in such a > way that I hope we will achieve the main desired result. Sometimes > that approach does not equal doing things the most theoretically > perfect way. If you are unhappy with my attempts to carry out my > role with the project, which is not only developer but manger and > coordinator, then I am happy to drop back to just being a developer > if you want to take over that coordinating role and move things in a > different direction, honestly, I could well do without the extra > grief. Up to you. > > You seem to be telling me to hurry up and finish the conversion to > > GRPC so that you don't have to feel slighted by being "stuck" on a > > branch that doesn't have the tag "MAIN" :) Hey, it's only a name! > > C'mon Kurt, why would I care about that? Man. My concern, which I've > restated several times, is that splitting active development over two > branches will be inefficient and not really in the best interests of the > project. I think that has proven What has "proven" this? What is the problem? It's been fine for me, what is the impact on you? There is nothing stopping you from doing any development you want. As I said, I'm not afraid of merges, and what I've seen so far is a couple hours' work, which is absolutely minor compared with what I've put in recently. The freedom from not worrying about screwing people up is well worth it to me. > to be the case. I reiterate that the idea of tagging a branch with > the old rpc code was a good one, but I don't think dividing our > developer effort was. [...] > > Once I get DS_RPC running in my sandbox, I'll run my little test suite > > on it and then do a merge to MAIN right away so we can be "on track". > > Yes, you may want to wait until I have a chance to sort out PyShell's > dirty AutoIndent code. I guess it doesn't matter though, as long as > those fixes are also propagated over to DS_RPC_BRANCH so that I'm not > knowingly leaving any major breakage there. I certainly don't want to merge anything that isn't working :) Actually, looking at the AutoIndent stuff, why "de-factor" it, especially if it is wired into EditorWindow.py in other than a trivial way? It increased the size of EditorWindow by over 50% to a rather bloated 1350 lines. (PyShell.py is only 875.) What's the advantage? Why not just revert it? Regards, KBK From elguavas@python.net Wed Sep 4 04:42:16 2002 From: elguavas@python.net (Stephen M. Gava) Date: 04 Sep 2002 13:42:16 +1000 Subject: [Idle-dev] DS_RPC_BRANCH In-Reply-To: References: <1031010413.535.24.camel@oberon> <1031101488.538.99.camel@oberon> Message-ID: <1031110937.538.165.camel@oberon> Kurt B. Kaiser wrote: > > Well, I guess that's just semantics. ;^) I call that "getting lost" at > > least temporarily, you call it "being wiped by accident then replaced". > > The net result for cvs users was that the patch was lost from recent > > checkouts. > > I would have croaked it even if we were working on one branch. Of course, *sigh*, the point is that if we were both working on the same branch the problem would've been detected and fixed much more quickly! That is the reality. I don't understand what you're not getting about that. > > Please re-read my earlier detailed response to this suggestion. I guess > > it sounds pretty simple to just pop out a release, but actually it's a > > lot of work. > > I'll be happy to do it. Especially if the VP guys would like one; we > haven't had one for a year. The vp guys have been perfectly happy waiting for our next release. Read Bruce's previous emails and the confusion you caused by attempting to change directions from the next release will have all the new code to the next release will be another half-baked one. Under my leadership we are aiming to _end_ the forking of _production_ idle, not give it a whole new lease of life. Bruce Sherwood and David Scherer, the two main vpython folk we've had contact with over the last year and a half have understood that and been happy with it and agreed with it, and Guido too. This decision was already made long ago; your butting in on the release manager job was unwelcome, not required, and as we have seen confusing and unhelpful to the vpython guys rather than useful to them. Re-read the last year and a half of idle-dev to get a clear handle on where we were going and why, I don't have time to keep on repeating it all to you. > > Again I think we must avoid nice sounding in theory makework that > > steals what little time we have between us away from what we > > actually need to be focusing our limited energies on: getting out > > some tarballs of 0.9x with all the new stuff in for people to test. > > Let me try and explain myself. My focus in all of this has not been > > on the most theoretically perfect way of proceeding, it has been > > purely on managing a project with very limited resources in such a > > way that I hope we will achieve the main desired result. Sometimes > > that approach does not equal doing things the most theoretically > > perfect way. If you are unhappy with my attempts to carry out my > > role with the project, which is not only developer but manger and > > coordinator, then I am happy to drop back to just being a developer > > if you want to take over that coordinating role and move things in a > > different direction, honestly, I could well do without the extra > > grief. > > Up to you. No, it's not only up to me. Read above where I said "If you are unhappy...", this was the point for you or anybody else reading this to support the job I've been doing so far. If that's not going to happen I don't feel I really have a choice. If Guido is happy to stamp your visa then when I get the chance to start "clearing my idlefork desk" tomorrow I'll punt all the project manager stuff over to you, say my goodbyes etc.. > What has "proven" this? What is the problem? It's been fine for me, > what is the impact on you? Hmm, maybe everything I already apparently wasted my time writing in my last long message about this. I'm so glad I took the time out of my day try to make it clear to you. > There is nothing stopping you from doing > any development you want. At the moment I'm not committing some patches because of reasons I already explained. I guess you didn't read that part either. > I certainly don't want to merge anything that isn't working :) Good. > Actually, looking at the AutoIndent stuff, why "de-factor" it, > especially if it is wired into EditorWindow.py in other than a trivial > way? It increased the size of EditorWindow by over 50% to a rather > bloated 1350 lines. (PyShell.py is only 875.) What's the advantage? > Why not just revert it? The reasons for moving several of the "required extensions" into the editor instead of leaving them as extensions is well documented in many earlier discussions on this list. Exactly how that happens is of course flexible. As for the relative size of EditorWindow and PyShell, so what? My concern with that situation is that there is a lot in PyShell that should probably really be other places, but that is historical dirt, like the messy direct references to the autoindent code that was supposedly an extension but which should probably have been merged into the main editor code long ago. Stephen. -- Stephen M. Gava http://python.net/crew/elguavas IDLEfork http://idlefork.sourceforge.net "just like IDLE, only crunchy" From guido@python.org Wed Sep 4 12:16:45 2002 From: guido@python.org (Guido van Rossum) Date: Wed, 04 Sep 2002 07:16:45 -0400 Subject: [Idle-dev] DS_RPC_BRANCH In-Reply-To: Your message of "Tue, 03 Sep 2002 18:00:57 EDT." References: <1031010413.535.24.camel@oberon> Message-ID: <200209041116.g84BGjo03300@pcp02138704pcs.reston01.va.comcast.net> > You seem to be telling me to hurry up and finish the conversion to > GRPC so that you don't have to feel slighted by being "stuck" on a > branch that doesn't have the tag "MAIN" :) Hey, it's only a name! > > It's not practical to do the kind of work I'm doing on the same > branch with other development. The changes I made were drastic and > you couldn't work on your tasks with me continually pulling the rug > out from under you by changing the whole design and internal code > structure. And I didn't want to tiptoe about worrying about screwing > you up. So the only question was, which branch is called "MAIN"? And > the reasonable answer was, the basic rpc design we were going to stay > with long term, because that puts DS_RPC in a terminating bugfix > side branch. It's _much_ easier to merge you to me than vice-versa! In my experience, this is unusual for a project. In Python, we have a rule that the CVS trunk at all times MUST be fully usable and pass all unit tests. Any work that cannot maintain this constraint has to be done on a branch (or, if it's small enough, it's done as a patch in SF that's never checked in). Zope does pretty much the same thing except it users branches more. I don't think that merging is any harder to merge to a branch than to the trunk (Zope uses long-living branches and the trunk is often merged back into the branch then). So IMO it's slightly unconventional that Kurt's redesign was done on the trunk and the stable version relegated to a branch. But what's done's done, and now that it's almost over, let's just remember not to make this mistake again in the future. --Guido van Rossum (home page: http://www.python.org/~guido/) From kbk@shore.net Wed Sep 4 18:00:50 2002 From: kbk@shore.net (Kurt B. Kaiser) Date: 04 Sep 2002 13:00:50 -0400 Subject: [Idle-dev] DS_RPC_BRANCH In-Reply-To: <1031110937.538.165.camel@oberon> References: <1031010413.535.24.camel@oberon> <1031101488.538.99.camel@oberon> <1031110937.538.165.camel@oberon> Message-ID: IMO any continuation of this discussion should be by private email. Regards, KBK From kbk@shore.net Wed Sep 4 20:33:04 2002 From: kbk@shore.net (Kurt B. Kaiser) Date: 04 Sep 2002 15:33:04 -0400 Subject: [Idle-dev] DS_RPC_BRANCH In-Reply-To: <200209041116.g84BGjo03300@pcp02138704pcs.reston01.va.comcast.net> References: <1031010413.535.24.camel@oberon> <200209041116.g84BGjo03300@pcp02138704pcs.reston01.va.comcast.net> Message-ID: Guido van Rossum writes: > So IMO it's slightly unconventional that Kurt's redesign was done on > the trunk and the stable version relegated to a branch. But what's > done's done, and now that it's almost over, let's just remember not to > make this mistake again in the future. Yeah, I won't try that again :) Too much aggravation for all concerned! The main disadvantage seems to be that potential cvs users are misled into checking out the transitional code when in fact they are looking for the stable version. Regards, KBK From elguavas@python.net Thu Sep 5 00:59:27 2002 From: elguavas@python.net (Stephen M. Gava) Date: 05 Sep 2002 09:59:27 +1000 Subject: [Idle-dev] DS_RPC_BRANCH In-Reply-To: References: <1031010413.535.24.camel@oberon> <1031101488.538.99.camel@oberon> <1031110937.538.165.camel@oberon> Message-ID: <1031183967.541.44.camel@oberon> Kurt B. Kaiser wrote: > IMO any continuation of this discussion should > be by private email. I tried that when I asked you not to interfere with the release plans, but you went ahead and did it anyway so it's a bit late for that. I've written to Guido asking if he's happy for you to take over as project manager as I don't need or want to continue doing that without your support. If that's the way he wants to go I'll start handing all my extra responsibilities over to you then. -- Stephen M. Gava http://python.net/crew/elguavas IDLEfork http://idlefork.sourceforge.net "just like IDLE, only crunchy" From guido@python.org Thu Sep 5 04:48:32 2002 From: guido@python.org (Guido van Rossum) Date: Wed, 04 Sep 2002 23:48:32 -0400 Subject: [Idle-dev] DS_RPC_BRANCH In-Reply-To: Your message of "Thu, 05 Sep 2002 09:59:27 +1000." <1031183967.541.44.camel@oberon> References: <1031010413.535.24.camel@oberon> <1031101488.538.99.camel@oberon> <1031110937.538.165.camel@oberon> <1031183967.541.44.camel@oberon> Message-ID: <200209050348.g853mX709495@pcp02138704pcs.reston01.va.comcast.net> > I tried that when I asked you not to interfere with the release plans, > but you went ahead and did it anyway so it's a bit late for that. I've > written to Guido asking if he's happy for you to take over as project > manager as I don't need or want to continue doing that without your > support. > > If that's the way he wants to go I'll start handing all my extra > responsibilities over to you then. Not so fast, Stephen. I like you to stay on if you don't mind. :-) I've sent Kurt & Stephen a longer private reply about this issue. We'll keep it private until a resolution is clear. --Guido van Rossum (home page: http://www.python.org/~guido/) From gvanrossum@users.sourceforge.net Thu Sep 5 03:54:36 2002 From: gvanrossum@users.sourceforge.net (Guido van Rossum) Date: Wed, 04 Sep 2002 19:54:36 -0700 Subject: [Idle-dev] CVS: idle PyShell.py,1.13.2.3,1.13.2.4 Message-ID: Update of /cvsroot/idlefork/idle In directory usw-pr-cvs1:/tmp/cvs-serv11096 Modified Files: Tag: DS_RPC_BRANCH PyShell.py Log Message: Quick fix to make this work again after the autoindent extension was merged into EditorWindow.py: self.auto.foo becomes self.foo, and self.auto disappears. Index: PyShell.py =================================================================== RCS file: /cvsroot/idlefork/idle/PyShell.py,v retrieving revision 1.13.2.3 retrieving revision 1.13.2.4 diff -C2 -r1.13.2.3 -r1.13.2.4 *** PyShell.py 6 Aug 2002 00:42:08 -0000 1.13.2.3 --- PyShell.py 5 Sep 2002 02:54:34 -0000 1.13.2.4 *************** *** 316,321 **** __builtin__.quit = __builtin__.exit = "To exit, type Ctrl-D." ! self.auto = self.extensions["AutoIndent"] # Required extension ! self.auto.config(usetabs=1, indentwidth=8, context_use_ps1=1) text = self.text --- 316,320 ---- __builtin__.quit = __builtin__.exit = "To exit, type Ctrl-D." ! self.config(usetabs=1, indentwidth=8, context_use_ps1=1) text = self.text *************** *** 424,428 **** self.interp = None self.console = None - self.auto = None self.flist.pyshell = None self.history = None --- 423,426 ---- *************** *** 529,533 **** self.text.see("insert") else: ! self.auto.auto_indent(event) return "break" --- 527,531 ---- self.text.see("insert") else: ! self.auto_indent(event) return "break" *************** *** 569,573 **** # insert a newline right at the insert point if self.text.compare("insert", "<", "end-1c linestart"): ! self.auto.auto_indent(event) return "break" # We're in the last line; append a newline and submit it --- 567,571 ---- # insert a newline right at the insert point if self.text.compare("insert", "<", "end-1c linestart"): ! self.auto_indent(event) return "break" # We're in the last line; append a newline and submit it *************** *** 577,581 **** self.text.see("insert") else: ! self.auto.auto_indent(event) self.text.tag_add("stdin", "iomark", "end-1c") self.text.update_idletasks() --- 575,579 ---- self.text.see("insert") else: ! self.auto_indent(event) self.text.tag_add("stdin", "iomark", "end-1c") self.text.update_idletasks() From kbk@users.sourceforge.net Thu Sep 5 03:31:22 2002 From: kbk@users.sourceforge.net (Kurt B. Kaiser) Date: Wed, 04 Sep 2002 19:31:22 -0700 Subject: [Idle-dev] CVS: idle PyShell.py,1.22,1.23 RemoteDebugger.py,1.6,1.7 ScriptBinding.py,1.8,1.9 Message-ID: Update of /cvsroot/idlefork/idle In directory usw-pr-cvs1:/tmp/cvs-serv1062 Modified Files: PyShell.py RemoteDebugger.py ScriptBinding.py Log Message: M PyShell.py M RemoteDebugger.py M ScriptBinding.py Restart the execution server with a clean environment and execute the active module from scratch upon activation of Run/F5. Add functionality to PyShell.py to restart the execution server in a new subprocess. The server makes a connection to the Idle client which sends a block of code to be executed. Modify ScriptBinding.py to restart the subprocess upon Run/F5, assuming that an execution is not currently in progress. Remove Import Module functionality, not required now that the code is executed in a clean environment. If the Debugger is active, also restart the subprocess side of the split debugger. Add functionality to RemoteDebugger.py to support this. At this time breakpoints will be lost in the subprocess if Run/F5 is activated. A subsequent checkin of PyShell.py will implement reloading of the breakpoints into the subprocess debugger. I'm keeping this separate as the design may change. Index: PyShell.py =================================================================== RCS file: /cvsroot/idlefork/idle/PyShell.py,v retrieving revision 1.22 retrieving revision 1.23 diff -C2 -r1.22 -r1.23 *** PyShell.py 5 Aug 2002 03:52:10 -0000 1.22 --- PyShell.py 5 Sep 2002 02:31:20 -0000 1.23 *************** *** 188,202 **** self.save_warnings_filters = None rpcclt = None rpcpid = None def spawn_subprocess(self): - port = 8833 - addr = ("localhost", port) - # Spawn the Python execution "server" w = ['-W' + s for s in sys.warnoptions] args = [sys.executable] + w + ["-c", "__import__('run').main()", ! str(port)] self.rpcpid = os.spawnv(os.P_NOWAIT, args[0], args) # Idle starts listening for connection on localhost for i in range(6): --- 188,204 ---- self.save_warnings_filters = None + port = 8833 rpcclt = None rpcpid = None def spawn_subprocess(self): w = ['-W' + s for s in sys.warnoptions] args = [sys.executable] + w + ["-c", "__import__('run').main()", ! str(self.port)] self.rpcpid = os.spawnv(os.P_NOWAIT, args[0], args) + + def start_subprocess(self): + addr = ("localhost", self.port) + self.spawn_subprocess() # Idle starts listening for connection on localhost for i in range(6): *************** *** 222,225 **** --- 224,242 ---- self.poll_subprocess() + def restart_subprocess(self): + # close only the subprocess debugger + db = self.getdebugger() + if db: + RemoteDebugger.close_subprocess_debugger(self.rpcclt) + # kill subprocess, spawn a new one, accept connection + self.rpcclt.close() + self.spawn_subprocess() + self.rpcclt.accept() + # restart remote debugger + if db: + gui = RemoteDebugger.restart_subprocess_debugger(self.rpcclt) + # reload remote debugger breakpoints + pass # XXX KBK 04Sep02 TBD + active_seq = None *************** *** 384,396 **** return self.debugger def runcommand(self, code): "Run the code without invoking the debugger" # The code better not raise an exception! if self.tkconsole.executing: ! tkMessageBox.showerror( ! "Already executing", ! "The Python Shell window is already executing a command; " ! "please wait until it is finished.", ! master=self.tkconsole.text) return 0 if self.rpcclt: --- 401,416 ---- return self.debugger + def display_executing_dialog(self): + tkMessageBox.showerror( + "Already executing", + "The Python Shell window is already executing a command; " + "please wait until it is finished.", + master=self.tkconsole.text) + def runcommand(self, code): "Run the code without invoking the debugger" # The code better not raise an exception! if self.tkconsole.executing: ! display_executing_dialog() return 0 if self.rpcclt: *************** *** 403,411 **** "Override base class method" if self.tkconsole.executing: ! tkMessageBox.showerror( ! "Already executing", ! "The Python Shell window is already executing a command; " ! "please wait until it is finished.", ! master=self.tkconsole.text) return # --- 423,427 ---- "Override base class method" if self.tkconsole.executing: ! display_executing_dialog() return # *************** *** 510,514 **** if use_subprocess: ! self.interp.spawn_subprocess() reading = 0 --- 526,530 ---- if use_subprocess: ! self.interp.start_subprocess() reading = 0 Index: RemoteDebugger.py =================================================================== RCS file: /cvsroot/idlefork/idle/RemoteDebugger.py,v retrieving revision 1.6 retrieving revision 1.7 diff -C2 -r1.6 -r1.7 *** RemoteDebugger.py 3 Jul 2002 03:55:43 -0000 1.6 --- RemoteDebugger.py 5 Sep 2002 02:31:20 -0000 1.7 *************** *** 28,31 **** --- 28,34 ---- debugging = 0 + idb_adap_oid = "idb_adapter" + gui_adap_oid = "gui_adapter" + #======================================= # *************** *** 114,117 **** --- 117,121 ---- def clear_break(self, filename, lineno): msg = self.idb.clear_break(filename, lineno) + return msg def clear_all_file_breaks(self, filename): *************** *** 184,188 **** idb = Debugger.Idb(gui_proxy) idb_adap = IdbAdapter(idb) - idb_adap_oid = "idb_adapter" rpchandler.register(idb_adap_oid, idb_adap) return idb_adap_oid --- 188,191 ---- *************** *** 326,329 **** --- 329,333 ---- def clear_break(self, filename, lineno): msg = self.call("clear_break", filename, lineno) + return msg def clear_all_file_breaks(self, filename): *************** *** 345,349 **** """ ! gui_adap_oid = "gui_adapter" idb_adap_oid = rpcclt.remotecall("exec", "start_the_debugger",\ (gui_adap_oid,), {}) --- 349,354 ---- """ ! global idb_adap_oid ! idb_adap_oid = rpcclt.remotecall("exec", "start_the_debugger",\ (gui_adap_oid,), {}) *************** *** 363,368 **** """ ! idb_adap_oid = "idb_adapter" ! rpcclt.remotecall("exec", "stop_the_debugger", (idb_adap_oid,), {}) ! gui_adap_oid = "gui_adapter" rpcclt.unregister(gui_adap_oid) --- 368,380 ---- """ ! close_subprocess_debugger(rpcclt) rpcclt.unregister(gui_adap_oid) + + def close_subprocess_debugger(rpcclt): + rpcclt.remotecall("exec", "stop_the_debugger", (idb_adap_oid,), {}) + + def restart_subprocess_debugger(rpcclt): + idb_adap_oid_ret = rpcclt.remotecall("exec", "start_the_debugger",\ + (gui_adap_oid,), {}) + assert idb_adap_oid_ret == idb_adap_oid, 'Idb restarted with different oid' + Index: ScriptBinding.py =================================================================== RCS file: /cvsroot/idlefork/idle/ScriptBinding.py,v retrieving revision 1.8 retrieving revision 1.9 diff -C2 -r1.8 -r1.9 *** ScriptBinding.py 25 Aug 2002 14:08:07 -0000 1.8 --- ScriptBinding.py 5 Sep 2002 02:31:20 -0000 1.9 *************** *** 6,16 **** It also runs the tabnanny to catch any inconsistent tabs. ! - Import module is equivalent to either import or reload of the ! current module. The window must have been saved previously. The ! module is added to sys.modules, and is also added to the __main__ ! namespace. Output goes to the shell window. ! ! - Run module does the same but executes the module's ! code in the __main__ namespace. XXX Redesign this interface (yet again) as follows: --- 6,12 ---- It also runs the tabnanny to catch any inconsistent tabs. ! - Run module executes the module's code in the __main__ namespace. The window ! must have been saved previously. The module is added to sys.modules, and is ! also added to the __main__ namespace. XXX Redesign this interface (yet again) as follows: *************** *** 20,25 **** - Allow specify command line arguments in the dialog box - - Restart the interpreter when running a script - """ --- 16,19 ---- *************** *** 48,52 **** ('run', [None, # ('Check module', '<>'), - # ('Import module', '<>'), ('Run script', '<>'), ] --- 42,45 ---- *************** *** 114,144 **** return 1 - def import_module_event(self, event): - flist = self.editwin.flist - shell = flist.open_shell() - interp = shell.interp - - filename = self.getfilename() - if not filename: - return - - modname, ext = os.path.splitext(os.path.basename(filename)) - - dir = os.path.dirname(filename) - dir = os.path.normpath(os.path.abspath(dir)) - - interp.runcode("""if 1: - import sys as _sys - if %s not in _sys.path: - _sys.path.insert(0, %s) - if _sys.modules.get(%s): - del _sys - import %s - reload(%s) - else: - del _sys - import %s - \n""" % (`dir`, `dir`, `modname`, modname, modname, modname)) - def run_script_event(self, event): filename = self.getfilename() --- 107,110 ---- *************** *** 148,151 **** --- 114,121 ---- shell = flist.open_shell() interp = shell.interp + if interp.tkconsole.executing: + interp.display_executing_dialog() + return + interp.restart_subprocess() # XXX Too often this discards arguments the user just set... interp.runcommand("""if 1: From elguavas@python.net Wed Sep 11 01:44:26 2002 From: elguavas@python.net (Stephen M. Gava) Date: 11 Sep 2002 10:44:26 +1000 Subject: [Idle-dev] idlefork handover Message-ID: <1031705067.705.154.camel@oberon> Greetings idleforkers and idlefork interested. After discussion with Guido and Kurt, and consideration of some reasons relating to my personal life, and in spite of being asked by Guido to stay on, I've decided to withdraw from my involvement with the idlefork project for now. I hand over the management aspects of the project to Kurt in full confidence that he will continue to do as excellent a job in those areas as he has in his other involvement with the project so far. The coding work I signed on for on the config back and frond ends is complete to first cut level and I'll continue to keep an eye on the list for now and of course be available to the guys on the project for questions about that. To the people I've had much contact with in my work on the project so far, David Scherer, Bruce Sherwood, Chui Tey, Kurt Kaiser, Raymond Hettinger, Fred Drake, (only a quick list off the top of my head) and of course Guido; it's been a real pleasure working with you all. I'm in the process of officially handing over all the necessary tasks and admin roles to Kurt at the moment. So, farewell, and thanks to everyone who's been interested in the project, Stephen. -- Stephen M. Gava http://python.net/crew/elguavas IDLEfork http://idlefork.sourceforge.net "just like IDLE, only crunchy" From elguavas@users.sourceforge.net Wed Sep 11 02:09:09 2002 From: elguavas@users.sourceforge.net (Stephen M. Gava) Date: Tue, 10 Sep 2002 18:09:09 -0700 Subject: [Idle-dev] CVS: website index.html,1.2,1.3 news.html,1.2,1.3 tasklist.txt,1.5,1.6 Message-ID: Update of /cvsroot/idlefork/website In directory usw-pr-cvs1:/tmp/cvs-serv3302 Modified Files: index.html news.html tasklist.txt Log Message: changes reflecting Kurt B. Kaiser as new project manager Index: index.html =================================================================== RCS file: /cvsroot/idlefork/website/index.html,v retrieving revision 1.2 retrieving revision 1.3 diff -C2 -r1.2 -r1.3 *** index.html 22 May 2002 00:38:21 -0000 1.2 --- index.html 11 Sep 2002 01:09:07 -0000 1.3 *************** *** 134,138 ****


How To Contribute

Everyone interested in IDLE is invited to contribute to the IDLEfork by ! means of discussion, bug reports and coding nifty patches. If you want to contribute code to IDLEfork regularly, you can become a developer by mailing the project coordinator, Stephen M. Gava. See the Developer Info page first.
 
Discussion --- 134,138 ----


How To Contribute

Everyone interested in IDLE is invited to contribute to the IDLEfork by ! means of discussion, bug reports and coding nifty patches. If you want to contribute code to IDLEfork regularly, you can become a developer by mailing the project coordinator, Kurt B. Kaiser. See the Developer Info page first.
 
Discussion Index: news.html =================================================================== RCS file: /cvsroot/idlefork/website/news.html,v retrieving revision 1.2 retrieving revision 1.3 diff -C2 -r1.2 -r1.3 *** news.html 6 Jun 2002 01:56:14 -0000 1.2 --- news.html 11 Sep 2002 01:09:07 -0000 1.3 *************** *** 126,129 **** --- 126,131 ----

Project News

+
10th September 2002 +

Kurt B. Kaiser takes over as new IDLEfork project coordinator. IDLEfork website 'Current Tasks' page updated.

6th June 2002

The IDLEfork project welcomes some new and returning developers aboard! IDLEfork website 'Current Tasks' page updated.

Index: tasklist.txt =================================================================== RCS file: /cvsroot/idlefork/website/tasklist.txt,v retrieving revision 1.5 retrieving revision 1.6 diff -C2 -r1.5 -r1.6 *** tasklist.txt 6 Jun 2002 02:11:00 -0000 1.5 --- tasklist.txt 11 Sep 2002 01:09:07 -0000 1.6 *************** *** 9,17 **** Project Admins. Guido van Rossum ! Stephen M. Gava ! Project Manager / Coordinator. Stephen M. Gava ! Release manager. Stephen M. Gava Mentor, Adviser, Final Arbiter. Guido van Rossum --- 9,17 ---- Project Admins. Guido van Rossum ! Kurt B. Kaiser ! Project Manager / Coordinator. Kurt B. Kaiser ! Release manager. Kurt B. Kaiser Mentor, Adviser, Final Arbiter. Guido van Rossum *************** *** 21,25 **** Ongoing branching, splicing & maintenance. Kurt B. Kaiser ! Tracking changes to stable python IDLE. Stephen M. Gava Everyone -------------------------------------------------------------------- --- 21,25 ---- Ongoing branching, splicing & maintenance. Kurt B. Kaiser ! Tracking changes to stable python IDLE. Kurt B. Kaiser Everyone -------------------------------------------------------------------- *************** *** 30,34 **** in-program help. ! IDLEfork website. Stephen M. Gava Context sensitive language/library help ? --- 30,34 ---- in-program help. ! IDLEfork website. Kurt B. Kaiser Context sensitive language/library help ? *************** *** 72,90 **** User Configuration / UI Improvements ! Overhaul configuration file handling. Stephen M. Gava ! Key binding configuration. Stephen M. Gava ! Font configuration. Stephen M. Gava ! Colour configuration. Stephen M. Gava ! Full GUI Configurability. Stephen M. Gava ! General look and feel issues Stephen M. Gava (appearance / consistency / uniform help access, etc.). ! About box. Stephen M. Gava -------------------------------------------------------------------- Program Startup Cleanup --- 72,90 ---- User Configuration / UI Improvements ! Overhaul configuration file handling. Done ! Key binding configuration. Done ! Font configuration. Done ! Colour configuration. Done ! Full GUI Configurability. Done ! General look and feel issues Done (appearance / consistency / uniform help access, etc.). ! About box. Done -------------------------------------------------------------------- Program Startup Cleanup From tony@lownds.com Wed Sep 11 02:12:16 2002 From: tony@lownds.com (Tony Lownds) Date: Tue, 10 Sep 2002 18:12:16 -0700 Subject: [Idle-dev] idlefork handover In-Reply-To: <1031705067.705.154.camel@oberon> References: <1031705067.705.154.camel@oberon> Message-ID: >So, farewell, >and thanks to everyone who's been interested in the project, Thanks Stephen, from an up-until-now silent party. -Tony From tony@lownds.com Wed Sep 11 02:17:28 2002 From: tony@lownds.com (Tony Lownds) Date: Tue, 10 Sep 2002 18:17:28 -0700 Subject: [Idle-dev] IDLE and Mac OS X Message-ID: Hi All, I've been silent until now but am starting to make patches for IDLE's smooth operation in OS X There are some installation and keyboard and Tk issues. I have a patch (606132, python.sf.net) that improves IDLE on OS X; Kurt or Guido, should I re-do all patches against idlefork too? What kind of synchronization is going to happen? Thanks -Tony From guido@python.org Wed Sep 11 03:39:48 2002 From: guido@python.org (Guido van Rossum) Date: Tue, 10 Sep 2002 22:39:48 -0400 Subject: [Idle-dev] idlefork handover In-Reply-To: Your message of "Wed, 11 Sep 2002 10:44:26 +1000." <1031705067.705.154.camel@oberon> References: <1031705067.705.154.camel@oberon> Message-ID: <200209110239.g8B2dm011113@pcp02138704pcs.reston01.va.comcast.net> [Stephen M. Gava] > After discussion with Guido and Kurt, and consideration of some > reasons relating to my personal life, and in spite of being asked by > Guido to stay on, I've decided to withdraw from my involvement with > the idlefork project for now. Stephen, thanks for being the idlefork project manager. I'm sorry you have decided to leave, but you've got to do what you've got to do. I trust that Kurt will be a competent replacement, though things will never be the same. Kurt, I believe your plans are to merge Stephen's work on the DS_RPC_BRANCH branch into the trunk, and then start preparing for a release, going through the usual alpha and beta releases pretty quickly. I propose to call that release IDLE 0.9. After that point, I propose that we focus on merging idlefork back into the fold of the Python project; that version should be IDLE 1.0. If we could do this before the release of Python 2.3, that would be great. At that point, the idlefork developers who want to continue to work on idle will be more than welcome to join the Python developers crew; the idlefork project at SourceForge can then be dismantled. (I see no reason to continue to idlefork as a separate project once it's been merged back into Python -- it has served its purpose.) [Tony Lownds] > I've been silent until now but am starting to make patches for IDLE's > smooth operation in OS X > > There are some installation and keyboard and Tk issues. I have a > patch (606132, python.sf.net) that improves IDLE on OS X; Kurt or > Guido, should I re-do all patches against idlefork too? What kind of > synchronization is going to happen? See above. The best thing for you would be to prepare patches for idlefork. (If you want to become an idlefork developer, that should be fine -- you can then apply the patches yourself, as long as Kurt agrees.) --Guido van Rossum (home page: http://www.python.org/~guido/) From elguavas@python.net Wed Sep 11 04:11:03 2002 From: elguavas@python.net (Stephen M. Gava) Date: 11 Sep 2002 13:11:03 +1000 Subject: [Idle-dev] idlefork handover In-Reply-To: <200209110239.g8B2dm011113@pcp02138704pcs.reston01.va.comcast.net> References: <1031705067.705.154.camel@oberon> <200209110239.g8B2dm011113@pcp02138704pcs.reston01.va.comcast.net> Message-ID: <1031713864.13929.32.camel@oberon> > I propose to call that release IDLE 0.9. I already updated idlever.py on DS_RPC_BRANCH to 0.9.1, so you can change that to 0.9 if you like when the branch to trunk merge happens. -- Stephen M. Gava http://python.net/crew/elguavas IDLEfork http://idlefork.sourceforge.net "just like IDLE, only crunchy" From kbk@users.sourceforge.net Thu Sep 12 00:17:39 2002 From: kbk@users.sourceforge.net (Kurt B. Kaiser) Date: Wed, 11 Sep 2002 16:17:39 -0700 Subject: [Idle-dev] CVS: idle Remote.py,1.2.2.1,1.2.2.2 Message-ID: Update of /cvsroot/idlefork/idle In directory usw-pr-cvs1:/tmp/cvs-serv18797 Added Files: Tag: DS_RPC_BRANCH Remote.py Log Message: Restore Remote.py, required by Scherer RPC From kbk@shore.net Thu Sep 12 20:03:22 2002 From: kbk@shore.net (Kurt B. Kaiser) Date: 12 Sep 2002 15:03:22 -0400 Subject: [Idle-dev] idlefork handover In-Reply-To: <1031705067.705.154.camel@oberon> References: <1031705067.705.154.camel@oberon> Message-ID: "Stephen M. Gava" writes: > Greetings idleforkers and idlefork interested. > > After discussion with Guido and Kurt, and consideration of some > reasons relating to my personal life, and in spite of being asked by > Guido to stay on, I've decided to withdraw from my involvement with > the idlefork project for now. I agree with Guido, I'm sorry to see you take this step. For those who tuned in late, Stephen has been carrying Idledev singlehanded for over a year and has been responsible for a complete overhaul of the configuration system. It is now possible for the user to set up Idle's appearance and keyboard interface as desired via a GUI. He has been tracking and merging the changes to Python Idle into Idlefork. Stephen also set up the Sourceforge configuration and integrated it with Idle-dev. And he designed and implemented the project's outstanding web page. > I hand over the management aspects of the project to Kurt in full > confidence that he will continue to do as excellent a job in those > areas as he has in his other involvement with the project so far. Thanks Stephen, and thank you very much for the extensive hand-over status report you sent me and also for the suggestions and hints on how best to use the Sourceforge and python.org interfaces. > The coding work I signed on for on the config back and frond ends is > complete to first cut level and I'll continue to keep an eye on the > list for now and of course be available to the guys on the project > for questions about that. > > To the people I've had much contact with in my work on the project so > far, David Scherer, Bruce Sherwood, Chui Tey, Kurt Kaiser, Raymond > Hettinger, Fred Drake, (only a quick list off the top of my head) and of > course Guido; it's been a real pleasure working with you all. > > I'm in the process of officially handing over all the necessary tasks > and admin roles to Kurt at the moment. > > So, farewell, > and thanks to everyone who's been interested in the project, > Stephen. As you assume your Idlefork Coordinator Emeritus position, I hope you'll be able to find time to hang around and keep an eye on us to make sure we don't go astray and muck up the good work you've done. Thanks again for the great contribution! :) Regards, KBK From kbk@shore.net Thu Sep 12 20:07:43 2002 From: kbk@shore.net (Kurt B. Kaiser) Date: 12 Sep 2002 15:07:43 -0400 Subject: [Idle-dev] idlefork handover In-Reply-To: <1031713864.13929.32.camel@oberon> References: <1031705067.705.154.camel@oberon> <200209110239.g8B2dm011113@pcp02138704pcs.reston01.va.comcast.net> <1031713864.13929.32.camel@oberon> Message-ID: "Stephen M. Gava" writes: > > I propose to call that release IDLE 0.9. > > I already updated idlever.py on DS_RPC_BRANCH to 0.9.1, so you can > change that to 0.9 if you like when the branch to trunk merge happens. I could set the DS_RPC_BRANCH to 0.8.9 KBK From kbk@shore.net Thu Sep 12 20:30:06 2002 From: kbk@shore.net (Kurt B. Kaiser) Date: 12 Sep 2002 15:30:06 -0400 Subject: [Idle-dev] IDLE and Mac OS X In-Reply-To: References: Message-ID: Tony Lownds writes: > I've been silent until now but am starting to make patches for IDLE's > smooth operation in OS X > > There are some installation and keyboard and Tk issues. I have a patch > (606132, python.sf.net) that improves IDLE on OS X; Kurt or Guido, > should I re-do all patches against idlefork too? What kind of > synchronization is going to happen? It's one of Idle's goals to be as crossplatform as possible. So your contribution is most welcome. Macs are a weak point for Idle. However, as they say, there is a slight difficulty :-( You have made modifications based on the old configuration system. The new one in Idlefork is a different approach, and most of the files in your patch no longer exist. If you can summon up the energy to revise it to use Stephen's implementation, that would be outstanding! I don't have the ability to test on Mac. As loewis said, it would be good if you could come up with another person to test the code. Maybe if there is someone on the list who uses OS X they could speak up? If you decide to go ahead, either check out the DS_RPC_BRANCH (where Stephen stripped the dead code), or wait a couple of days for me to merge with MAIN. The checkout of DS_RPC is cd to ~/proj/sandbox [or any nice place you have :] cvs -d:pserver:anonymous@cvs.idlefork.sourceforge.net:/cvsroot/idlefork login cvs -d:pserver:anonymous@cvs.idlefork.sourceforge.net:/cvsroot/idlefork co -didlefork -rDS_RPC_BRANCH idle Thanks, KBK From tony@lownds.com Thu Sep 12 21:15:16 2002 From: tony@lownds.com (Tony Lownds) Date: Thu, 12 Sep 2002 13:15:16 -0700 Subject: [Idle-dev] IDLE and Mac OS X In-Reply-To: References: Message-ID: At 3:30 PM -0400 9/12/02, Kurt B. Kaiser wrote: >However, as they say, there is a slight difficulty :-( > >You have made modifications based on the old configuration system. >The new one in Idlefork is a different approach, and most of the files >in your patch no longer exist. > >If you can summon up the energy to revise it to use Stephen's >implementation, that would be outstanding! I'll do my best! I'll work against the DS_RPC_BRANCH for now. >I don't have the ability to test on Mac. As loewis said, it would be >good if you could come up with another person to test the code. Maybe >if there is someone on the list who uses OS X they could speak up? Yes please - and if you need a pre-packaged binary, let me know. Thanks, -Tony From tony@lownds.com Thu Sep 12 21:15:28 2002 From: tony@lownds.com (Tony Lownds) Date: Thu, 12 Sep 2002 13:15:28 -0700 Subject: [Idle-dev] IDLE and Mac OS X In-Reply-To: References: Message-ID: --============_-1180260764==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" One thing I've already noticed: I was using Tools/idle/idle as the bootstrap script. That script imports a package named "idlelib", and that fits the OSX applet model quite well. In idlefork, none of the startup scripts seem to use a separate package. Furthermore, if I tweak the startup scripts to use a package I get a exception #! /usr/bin/env python from idlelib import PyShell PyShell.main() Failed to load extension 'ExecBinding' Traceback (most recent call last): File "/Applications/Python/IDLE.app/Contents/Resources/idlelib/EditorWindow.py", line 691, in load_standard_extensions self.load_extension(name) File "/Applications/Python/IDLE.app/Contents/Resources/idlelib/EditorWindow.py", line 701, in load_extension mod = __import__(name, globals(), locals(), []) File "/Applications/Python/IDLE.app/Contents/Resources/idlelib/ExecBinding.py", line 30, in ? load_py = spawn.hardpath( imp.find_module("loader")[1] ) ImportError: No module named loader Right now I'm using a startup script like: #! /usr/bin/env python # add "idlelib", a sibling of the file, to the path import sys, os sys.path.append(os.path.join(os.path.split(__file__)[0], 'idlelib')) import PyShell PyShell.main() What will IDLE 0.9 do? Thanks, -Tony --============_-1180260764==_ma============ Content-Type: text/html; charset="us-ascii" Re: [Idle-dev] IDLE and Mac OS X

One thing I've already noticed: I was using Tools/idle/idle as the bootstrap script. That script imports a package named "idlelib", and that fits the OSX applet model quite well.

In idlefork, none of the startup scripts seem to use a separate package. Furthermore, if I tweak the startup scripts to use a package I get a exception

#! /usr/bin/env python

from idlelib import PyShell
PyShell.main()

Failed to load extension 'ExecBinding'
Traceback (most recent call last):
  File "/Applications/Python/IDLE.app/Contents/Resources/idlelib/EditorWindow.py", line 691, in load_standard_extensions
    self.load_extension(name)
  File "/Applications/Python/IDLE.app/Contents/Resources/idlelib/EditorWindow.py", line 701, in load_extension
    mod = __import__(name, globals(), locals(), [])
  File "/Applications/Python/IDLE.app/Contents/Resources/idlelib/ExecBinding.py", line 30, in ?
    load_py  = spawn.hardpath( imp.find_module("loader")[1] )
ImportError: No module named loader

Right now I'm using a startup script like:

#! /usr/bin/env python

# add "idlelib", a sibling of the file, to the path
import sys, os
sys.path.append(os.path.join(os.path.split(__file__)[0], 'idlelib'))

import PyShell
PyShell.main()

What will IDLE 0.9 do?


Thanks,
-Tony
--============_-1180260764==_ma============-- From kbk@users.sourceforge.net Thu Sep 12 21:55:45 2002 From: kbk@users.sourceforge.net (Kurt B. Kaiser) Date: Thu, 12 Sep 2002 13:55:45 -0700 Subject: [Idle-dev] CVS: idle INSTALL.txt,1.1,1.2 Message-ID: Update of /cvsroot/idlefork/idle In directory usw-pr-cvs1:/tmp/cvs-serv29183 Modified Files: INSTALL.txt Log Message: Merge from DS_RPC_BRANCH Modified Files: INSTALL.txt Index: INSTALL.txt =================================================================== RCS file: /cvsroot/idlefork/idle/INSTALL.txt,v retrieving revision 1.1 retrieving revision 1.2 diff -C2 -r1.1 -r1.2 *** INSTALL.txt 21 Jul 2001 09:50:55 -0000 1.1 --- INSTALL.txt 12 Sep 2002 20:55:43 -0000 1.2 *************** *** 46,55 **** # python setup.py install ! # echo "idle" > /usr/local/lib/pythonX.X/site-packages.pth This last is necessary so idle can find itself. I hope we can create/append this file via setup.py at some point, but it needs to be done manually now, and it only needs to be done once (unless you totally remove and reinstall python ! itself). # exit from root --- 46,55 ---- # python setup.py install ! # echo idlelib >> /usr/local/lib/pythonX.X/site-packages/site-packages.pth This last is necessary so idle can find itself. I hope we can create/append this file via setup.py at some point, but it needs to be done manually now, and it only needs to be done once (unless you totally remove and reinstall python ! itself). (Replace X.X with the correct version for your Python.) # exit from root From linux@foolswisdom.org Thu Sep 12 21:02:42 2002 From: linux@foolswisdom.org (Lloyd D Budd) Date: 12 Sep 2002 13:02:42 -0700 Subject: [Idle-dev] anti-mission statement Message-ID: <1031860962.1390.105.camel@foolm.foolswisdom> Hello all, Just getting started with python. Letting you know that the idle-fork website and specifically the mission statement does not make much sense to an outsider. It does not identify the diff b/w idle devel and idle-fork devel, if there is one. It also does not make it clear if idle and idle-fork are the same thing, or if they are not, who's mission statement that is. Cheers, Lloyd D Budd From kbk@shore.net Fri Sep 13 05:07:35 2002 From: kbk@shore.net (Kurt B. Kaiser) Date: 13 Sep 2002 00:07:35 -0400 Subject: [Idle-dev] anti-mission statement In-Reply-To: <1031860962.1390.105.camel@foolm.foolswisdom> References: <1031860962.1390.105.camel@foolm.foolswisdom> Message-ID: Lloyd D Budd writes: > Just getting started with python. Letting you know that the idle-fork > website and specifically the mission statement does not make much sense > to an outsider. It does not identify the diff b/w idle devel and > idle-fork devel, if there is one. It also does not make it clear if > idle and idle-fork are the same thing, or if they are not, who's mission > statement that is. Lloyd, thanks for the anti-anti-mission statement, I guess ;) We will clap on our newbie goggles and take another look at that guy. The exec summary is that Idlefork is a low protocol (no PEPs [yet :-]) development branch of Idle which will be rolled back into Python RSN. Thanks for the input. Welcome to Python! KBK From kbk@shore.net Fri Sep 13 05:30:37 2002 From: kbk@shore.net (Kurt B. Kaiser) Date: 13 Sep 2002 00:30:37 -0400 Subject: [Idle-dev] IDLE and Mac OS X In-Reply-To: References: Message-ID: Tony Lownds writes: > One thing I've already noticed: I was using Tools/idle/idle as the > bootstrap script. That script imports a package named "idlelib", and > that fits the OSX applet model quite well. > > In idlefork, none of the startup scripts seem to use a separate > package. If you look at CVS you'll see that I probably chopped more out of the "idle" script a year or so ago than I should have. Also take a look at the INSTALL.txt file which has details regarding the idlelib package. We've been doing quick turn-arounds by executing "python idle.py" in the idlefork directory and not paying much attention to proper installation yet. I'll take another look. > Furthermore, if I tweak the startup scripts to use a package I get a > exception [...] > ImportError: No module named loader Try a fresh checkout of DS_RPC_BRANCH. loader.py and Remote.py have been restored recently. > > Right now I'm using a startup script like: > > #! /usr/bin/env python > > # add "idlelib", a sibling of the file, to the path > import sys, os > sys.path.append(os.path.join(os.path.split(__file__)[0], 'idlelib')) > > import PyShell > PyShell.main() > > What will IDLE 0.9 do? > It will install using its setup.py as .../PythonX.X/sitepackages/Idle Regards, KBK From tony@lownds.com Fri Sep 13 16:28:10 2002 From: tony@lownds.com (Tony Lownds) Date: Fri, 13 Sep 2002 08:28:10 -0700 Subject: [Idle-dev] IDLE and Mac OS X In-Reply-To: References: Message-ID: At 12:30 AM -0400 9/13/02, Kurt B. Kaiser wrote: >Tony Lownds writes: > >> One thing I've already noticed: I was using Tools/idle/idle as the >> bootstrap script. That script imports a package named "idlelib", and >> that fits the OSX applet model quite well. >> >> In idlefork, none of the startup scripts seem to use a separate >> package. > >If you look at CVS you'll see that I probably chopped more out of the >"idle" script a year or so ago than I should have. Also take a look >at the INSTALL.txt file which has details regarding the idlelib >package. > >We've been doing quick turn-arounds by executing "python idle.py" in >the idlefork directory and not paying much attention to proper >installation yet. I'll take another look. I'm happy to use the script I posted while developing. FYI "python idle.py" won't pull up a GUI on OSX (I'm planning on looking at the remote execution code to seeifthat will cause problems soon) > > Furthermore, if I tweak the startup scripts to use a package I get a >> exception > >[...] > >> ImportError: No module named loader > >Try a fresh checkout of DS_RPC_BRANCH. loader.py and Remote.py have >been restored recently. I did have those. I thought the exception was happening because imp.find_module, and the fact that I was loading PyShell from a package, were interacting badly. Running some simple tests on imp aren't bearing out my hypothesis, yet I still get the error if I start idle like this: from idlelib import PyShell PyShell.main() ...like it is done in Python's cvs. >It will install using its setup.py as .../PythonX.X/sitepackages/Idle > So Idle will be accessed as a package on the path. When you run idle using "python idle.py" you have the idle directory on the path directly, not as a package on the path. Since idle will install as a package on a path, would you try running it as such to see if you get the same error (ImportError: No module named "loader") ... I just want to make sure my platform isn't crazy... i.e. cd .. python -c "from idle import PyShell; PyShell.main()" -Tony From kbk@shore.net Fri Sep 13 19:09:57 2002 From: kbk@shore.net (Kurt B. Kaiser) Date: 13 Sep 2002 14:09:57 -0400 Subject: [Idle-dev] ANNOUNCE -- New Idlefork Developers Message-ID: Please welcome two new developers to the Idlefork project! Neal Norwitz is the author of PyChecker ("lint for Python"). I suspect that he's going to turn his microscope on the Idlefork code and discover a bunch of nasties, giving new meaning to the term "software RAID." Tony Lownds is working on porting Python and specifically Idle to Mac OS X. He's authored web pages which provide code, instructions, and screenshots for Python/OSX. Tony is already attacking problems related to getting Idlefork running on his Mac. Give these guys a round of applause for jumping in here! KBK From tony@lownds.com Fri Sep 13 20:07:56 2002 From: tony@lownds.com (Tony Lownds) Date: Fri, 13 Sep 2002 12:07:56 -0700 Subject: [Idle-dev] ANNOUNCE -- New Idlefork Developers In-Reply-To: References: Message-ID: At 2:09 PM -0400 9/13/02, Kurt B. Kaiser wrote: >Please welcome two new developers to the Idlefork project! Thanks Kurt >Neal Norwitz is the author of PyChecker ("lint for Python"). I >suspect that he's going to turn his microscope on the Idlefork >code and discover a bunch of nasties, giving new meaning to >the term "software RAID." Or perhaps he will add PyChecker as a graphical extension to IDLE - Neal, the public is dying to know! -Tony From kbk@users.sourceforge.net Fri Sep 13 21:37:19 2002 From: kbk@users.sourceforge.net (Kurt B. Kaiser) Date: Fri, 13 Sep 2002 13:37:19 -0700 Subject: [Idle-dev] CVS: idle idlever.py,1.5.2.1,1.5.2.2 Message-ID: Update of /cvsroot/idlefork/idle In directory usw-pr-cvs1:/tmp/cvs-serv29839 Modified Files: Tag: DS_RPC_BRANCH idlever.py Log Message: Set the version on DS_RPC_BRANCH back a notch to allow MAIN to be 0.8.9 after the merge. Index: idlever.py =================================================================== RCS file: /cvsroot/idlefork/idle/idlever.py,v retrieving revision 1.5.2.1 retrieving revision 1.5.2.2 diff -C2 -r1.5.2.1 -r1.5.2.2 *** idlever.py 22 Jul 2002 03:09:50 -0000 1.5.2.1 --- idlever.py 13 Sep 2002 20:37:17 -0000 1.5.2.2 *************** *** 1 **** ! IDLE_VERSION = "0.9.1" --- 1 ---- ! IDLE_VERSION = "0.8.8" From kbk@users.sourceforge.net Sat Sep 14 01:50:46 2002 From: kbk@users.sourceforge.net (Kurt B. Kaiser) Date: Fri, 13 Sep 2002 17:50:46 -0700 Subject: [Idle-dev] CVS: idle Bindings.py,1.10,1.11 Message-ID: Update of /cvsroot/idlefork/idle In directory usw-pr-cvs1:/tmp/cvs-serv2244 Modified Files: Bindings.py Log Message: Bindings.py AutoIndent merged 21Jul cleanup and remove references to config backend 06Aug Index: Bindings.py =================================================================== RCS file: /cvsroot/idlefork/idle/Bindings.py,v retrieving revision 1.10 retrieving revision 1.11 diff -C2 -r1.10 -r1.11 *** Bindings.py 11 Jun 2002 04:45:32 -0000 1.10 --- Bindings.py 14 Sep 2002 00:50:44 -0000 1.11 *************** *** 6,19 **** # Debug menu here, which is only present in the PythonShell window. - # changes by dscherer@cmu.edu: - # - Python shell moved to 'Run' menu - # - "Help" renamed to "IDLE Help" to distinguish from Python help. - # The distinction between the environment and the language is dim - # or nonexistent in a novice's mind. - # - Silly advice added - import sys import string - #from keydefs import * from configHandler import idleConf --- 6,11 ---- *************** *** 52,55 **** --- 44,57 ---- ('Go to _line', '<>'), ]), + ('format', [ + ('_Indent region', '<>'), + ('_Dedent region', '<>'), + ('Comment _out region', '<>'), + ('U_ncomment region', '<>'), + ('Tabify region', '<>'), + ('Untabify region', '<>'), + ('Toggle tabs', '<>'), + ('New indent width', '<>'), + ]), ('run',[ ('Python shell', '<>'), From kbk@users.sourceforge.net Sat Sep 14 01:55:23 2002 From: kbk@users.sourceforge.net (Kurt B. Kaiser) Date: Fri, 13 Sep 2002 17:55:23 -0700 Subject: [Idle-dev] CVS: idle CallTips.py,1.4,1.5 Message-ID: Update of /cvsroot/idlefork/idle In directory usw-pr-cvs1:/tmp/cvs-serv3217 Modified Files: CallTips.py Log Message: MERGE DS_RPC_BRANCH into MAIN CallTips track Py Idle loewis: Use ascii_letters to avoid UnicodeErrors 06Aug Index: CallTips.py =================================================================== RCS file: /cvsroot/idlefork/idle/CallTips.py,v retrieving revision 1.4 retrieving revision 1.5 diff -C2 -r1.4 -r1.5 *** CallTips.py 19 Jan 2002 10:39:47 -0000 1.4 --- CallTips.py 14 Sep 2002 00:55:21 -0000 1.5 *************** *** 64,68 **** def get_object_at_cursor(self, ! wordchars="._" + string.uppercase + string.lowercase + string.digits): # XXX - This needs to be moved to a better place # so the "." attribute lookup code can also use it. --- 64,71 ---- def get_object_at_cursor(self, ! wordchars="._" + string.ascii_letters + string.digits): ! # Usage of ascii_letters is necessary to avoid UnicodeErrors ! # if chars contains non-ASCII. ! # XXX - This needs to be moved to a better place # so the "." attribute lookup code can also use it. From kbk@users.sourceforge.net Sat Sep 14 03:34:25 2002 From: kbk@users.sourceforge.net (Kurt B. Kaiser) Date: Fri, 13 Sep 2002 19:34:25 -0700 Subject: [Idle-dev] CVS: idle EditorWindow.py,1.27,1.28 Message-ID: Update of /cvsroot/idlefork/idle In directory usw-pr-cvs1:/tmp/cvs-serv21713 Modified Files: EditorWindow.py Log Message: MERGE DS_RPC_BRANCH into MAIN EditorWindow.py AutoIndent merged 21Jul Comment out debug messages 21Jul Index: EditorWindow.py =================================================================== RCS file: /cvsroot/idlefork/idle/EditorWindow.py,v retrieving revision 1.27 retrieving revision 1.28 diff -C2 -r1.27 -r1.28 *** EditorWindow.py 11 Jul 2002 04:33:41 -0000 1.27 --- EditorWindow.py 14 Sep 2002 02:34:23 -0000 1.28 *************** *** 14,17 **** --- 14,18 ---- import GrepDialog import ReplaceDialog + import PyParse #from IdleConf import idleconf from configHandler import idleConf *************** *** 142,145 **** --- 143,158 ---- text.bind("<>", self.goto_line_event) text.bind("<3>", self.right_menu_event) + text.bind("<>",self.smart_backspace_event) + text.bind("<>",self.newline_and_indent_event) + text.bind("<>",self.smart_indent_event) + text.bind("<>",self.indent_region_event) + text.bind("<>",self.dedent_region_event) + text.bind("<>",self.comment_region_event) + text.bind("<>",self.uncomment_region_event) + text.bind("<>",self.tabify_region_event) + text.bind("<>",self.untabify_region_event) + text.bind("<>",self.toggle_tabs_event) + text.bind("<>",self.change_indentwidth_event) + if flist: flist.inversedict[self] = key *************** *** 876,879 **** --- 889,1359 ---- "n" * newtabwidth) text.configure(tabs=pixels) + + ### begin autoindent code ### + + # usetabs true -> literal tab characters are used by indent and + # dedent cmds, possibly mixed with spaces if + # indentwidth is not a multiple of tabwidth + # false -> tab characters are converted to spaces by indent + # and dedent cmds, and ditto TAB keystrokes + # indentwidth is the number of characters per logical indent level. + # tabwidth is the display width of a literal tab character. + # CAUTION: telling Tk to use anything other than its default + # tab setting causes it to use an entirely different tabbing algorithm, + # treating tab stops as fixed distances from the left margin. + # Nobody expects this, so for now tabwidth should never be changed. + usetabs = 0 + indentwidth = 4 + tabwidth = 8 # for IDLE use, must remain 8 until Tk is fixed + + # If context_use_ps1 is true, parsing searches back for a ps1 line; + # else searches for a popular (if, def, ...) Python stmt. + context_use_ps1 = 0 + + # When searching backwards for a reliable place to begin parsing, + # first start num_context_lines[0] lines back, then + # num_context_lines[1] lines back if that didn't work, and so on. + # The last value should be huge (larger than the # of lines in a + # conceivable file). + # Making the initial values larger slows things down more often. + num_context_lines = 50, 500, 5000000 + + def config(self, **options): + for key, value in options.items(): + if key == 'usetabs': + self.usetabs = value + elif key == 'indentwidth': + self.indentwidth = value + elif key == 'tabwidth': + self.tabwidth = value + elif key == 'context_use_ps1': + self.context_use_ps1 = value + else: + raise KeyError, "bad option name: %s" % `key` + + # If ispythonsource and guess are true, guess a good value for + # indentwidth based on file content (if possible), and if + # indentwidth != tabwidth set usetabs false. + # In any case, adjust the Text widget's view of what a tab + # character means. + + def set_indentation_params(self, ispythonsource, guess=1): + if guess and ispythonsource: + i = self.guess_indent() + if 2 <= i <= 8: + self.indentwidth = i + if self.indentwidth != self.tabwidth: + self.usetabs = 0 + + self.set_tabwidth(self.tabwidth) + + def smart_backspace_event(self, event): + text = self.text + first, last = self.get_selection_indices() + if first and last: + text.delete(first, last) + text.mark_set("insert", first) + return "break" + # Delete whitespace left, until hitting a real char or closest + # preceding virtual tab stop. + chars = text.get("insert linestart", "insert") + if chars == '': + if text.compare("insert", ">", "1.0"): + # easy: delete preceding newline + text.delete("insert-1c") + else: + text.bell() # at start of buffer + return "break" + if chars[-1] not in " \t": + # easy: delete preceding real char + text.delete("insert-1c") + return "break" + # Ick. It may require *inserting* spaces if we back up over a + # tab character! This is written to be clear, not fast. + expand, tabwidth = string.expandtabs, self.tabwidth + have = len(expand(chars, tabwidth)) + assert have > 0 + want = ((have - 1) // self.indentwidth) * self.indentwidth + ncharsdeleted = 0 + while 1: + chars = chars[:-1] + ncharsdeleted = ncharsdeleted + 1 + have = len(expand(chars, tabwidth)) + if have <= want or chars[-1] not in " \t": + break + text.undo_block_start() + text.delete("insert-%dc" % ncharsdeleted, "insert") + if have < want: + text.insert("insert", ' ' * (want - have)) + text.undo_block_stop() + return "break" + + def smart_indent_event(self, event): + # if intraline selection: + # delete it + # elif multiline selection: + # do indent-region & return + # indent one level + text = self.text + first, last = self.get_selection_indices() + text.undo_block_start() + try: + if first and last: + if index2line(first) != index2line(last): + return self.indent_region_event(event) + text.delete(first, last) + text.mark_set("insert", first) + prefix = text.get("insert linestart", "insert") + raw, effective = classifyws(prefix, self.tabwidth) + if raw == len(prefix): + # only whitespace to the left + self.reindent_to(effective + self.indentwidth) + else: + if self.usetabs: + pad = '\t' + else: + effective = len(string.expandtabs(prefix, + self.tabwidth)) + n = self.indentwidth + pad = ' ' * (n - effective % n) + text.insert("insert", pad) + text.see("insert") + return "break" + finally: + text.undo_block_stop() + + def newline_and_indent_event(self, event): + text = self.text + first, last = self.get_selection_indices() + text.undo_block_start() + try: + if first and last: + text.delete(first, last) + text.mark_set("insert", first) + line = text.get("insert linestart", "insert") + i, n = 0, len(line) + while i < n and line[i] in " \t": + i = i+1 + if i == n: + # the cursor is in or at leading indentation; just inject + # an empty line at the start + text.insert("insert linestart", '\n') + return "break" + indent = line[:i] + # strip whitespace before insert point + i = 0 + while line and line[-1] in " \t": + line = line[:-1] + i = i+1 + if i: + text.delete("insert - %d chars" % i, "insert") + # strip whitespace after insert point + while text.get("insert") in " \t": + text.delete("insert") + # start new line + text.insert("insert", '\n') + + # adjust indentation for continuations and block + # open/close first need to find the last stmt + lno = index2line(text.index('insert')) + y = PyParse.Parser(self.indentwidth, self.tabwidth) + for context in self.num_context_lines: + startat = max(lno - context, 1) + startatindex = `startat` + ".0" + rawtext = text.get(startatindex, "insert") + y.set_str(rawtext) + bod = y.find_good_parse_start( + self.context_use_ps1, + self._build_char_in_string_func(startatindex)) + if bod is not None or startat == 1: + break + y.set_lo(bod or 0) + c = y.get_continuation_type() + if c != PyParse.C_NONE: + # The current stmt hasn't ended yet. + if c == PyParse.C_STRING: + # inside a string; just mimic the current indent + text.insert("insert", indent) + elif c == PyParse.C_BRACKET: + # line up with the first (if any) element of the + # last open bracket structure; else indent one + # level beyond the indent of the line with the + # last open bracket + self.reindent_to(y.compute_bracket_indent()) + elif c == PyParse.C_BACKSLASH: + # if more than one line in this stmt already, just + # mimic the current indent; else if initial line + # has a start on an assignment stmt, indent to + # beyond leftmost =; else to beyond first chunk of + # non-whitespace on initial line + if y.get_num_lines_in_stmt() > 1: + text.insert("insert", indent) + else: + self.reindent_to(y.compute_backslash_indent()) + else: + assert 0, "bogus continuation type " + `c` + return "break" + + # This line starts a brand new stmt; indent relative to + # indentation of initial line of closest preceding + # interesting stmt. + indent = y.get_base_indent_string() + text.insert("insert", indent) + if y.is_block_opener(): + self.smart_indent_event(event) + elif indent and y.is_block_closer(): + self.smart_backspace_event(event) + return "break" + finally: + text.see("insert") + text.undo_block_stop() + + auto_indent = newline_and_indent_event + + # Our editwin provides a is_char_in_string function that works + # with a Tk text index, but PyParse only knows about offsets into + # a string. This builds a function for PyParse that accepts an + # offset. + + def _build_char_in_string_func(self, startindex): + def inner(offset, _startindex=startindex, + _icis=self.is_char_in_string): + return _icis(_startindex + "+%dc" % offset) + return inner + + def indent_region_event(self, event): + head, tail, chars, lines = self.get_region() + for pos in range(len(lines)): + line = lines[pos] + if line: + raw, effective = classifyws(line, self.tabwidth) + effective = effective + self.indentwidth + lines[pos] = self._make_blanks(effective) + line[raw:] + self.set_region(head, tail, chars, lines) + return "break" + + def dedent_region_event(self, event): + head, tail, chars, lines = self.get_region() + for pos in range(len(lines)): + line = lines[pos] + if line: + raw, effective = classifyws(line, self.tabwidth) + effective = max(effective - self.indentwidth, 0) + lines[pos] = self._make_blanks(effective) + line[raw:] + self.set_region(head, tail, chars, lines) + return "break" + + def comment_region_event(self, event): + head, tail, chars, lines = self.get_region() + for pos in range(len(lines) - 1): + line = lines[pos] + lines[pos] = '##' + line + self.set_region(head, tail, chars, lines) + + def uncomment_region_event(self, event): + head, tail, chars, lines = self.get_region() + for pos in range(len(lines)): + line = lines[pos] + if not line: + continue + if line[:2] == '##': + line = line[2:] + elif line[:1] == '#': + line = line[1:] + lines[pos] = line + self.set_region(head, tail, chars, lines) + + def tabify_region_event(self, event): + head, tail, chars, lines = self.get_region() + tabwidth = self._asktabwidth() + for pos in range(len(lines)): + line = lines[pos] + if line: + raw, effective = classifyws(line, tabwidth) + ntabs, nspaces = divmod(effective, tabwidth) + lines[pos] = '\t' * ntabs + ' ' * nspaces + line[raw:] + self.set_region(head, tail, chars, lines) + + def untabify_region_event(self, event): + head, tail, chars, lines = self.get_region() + tabwidth = self._asktabwidth() + for pos in range(len(lines)): + lines[pos] = string.expandtabs(lines[pos], tabwidth) + self.set_region(head, tail, chars, lines) + + def toggle_tabs_event(self, event): + if self.askyesno( + "Toggle tabs", + "Turn tabs " + ("on", "off")[self.usetabs] + "?", + parent=self.text): + self.usetabs = not self.usetabs + return "break" + + # XXX this isn't bound to anything -- see class tabwidth comments + def change_tabwidth_event(self, event): + new = self._asktabwidth() + if new != self.tabwidth: + self.tabwidth = new + self.set_indentation_params(0, guess=0) + return "break" + + def change_indentwidth_event(self, event): + new = self.askinteger( + "Indent width", + "New indent width (2-16)", + parent=self.text, + initialvalue=self.indentwidth, + minvalue=2, + maxvalue=16) + if new and new != self.indentwidth: + self.indentwidth = new + return "break" + + def get_region(self): + text = self.text + first, last = self.get_selection_indices() + if first and last: + head = text.index(first + " linestart") + tail = text.index(last + "-1c lineend +1c") + else: + head = text.index("insert linestart") + tail = text.index("insert lineend +1c") + chars = text.get(head, tail) + lines = string.split(chars, "\n") + return head, tail, chars, lines + + def set_region(self, head, tail, chars, lines): + text = self.text + newchars = string.join(lines, "\n") + if newchars == chars: + text.bell() + return + text.tag_remove("sel", "1.0", "end") + text.mark_set("insert", head) + text.undo_block_start() + text.delete(head, tail) + text.insert(head, newchars) + text.undo_block_stop() + text.tag_add("sel", head, "insert") + + # Make string that displays as n leading blanks. + + def _make_blanks(self, n): + if self.usetabs: + ntabs, nspaces = divmod(n, self.tabwidth) + return '\t' * ntabs + ' ' * nspaces + else: + return ' ' * n + + # Delete from beginning of line to insert point, then reinsert + # column logical (meaning use tabs if appropriate) spaces. + + def reindent_to(self, column): + text = self.text + text.undo_block_start() + if text.compare("insert linestart", "!=", "insert"): + text.delete("insert linestart", "insert") + if column: + text.insert("insert", self._make_blanks(column)) + text.undo_block_stop() + + def _asktabwidth(self): + return self.askinteger( + "Tab width", + "Spaces per tab? (2-16)", + parent=self.text, + initialvalue=self.indentwidth, + minvalue=2, + maxvalue=16) or self.tabwidth + + # Guess indentwidth from text content. + # Return guessed indentwidth. This should not be believed unless + # it's in a reasonable range (e.g., it will be 0 if no indented + # blocks are found). + + def guess_indent(self): + opener, indented = IndentSearcher(self.text, self.tabwidth).run() + if opener and indented: + raw, indentsmall = classifyws(opener, self.tabwidth) + raw, indentlarge = classifyws(indented, self.tabwidth) + else: + indentsmall = indentlarge = 0 + return indentlarge - indentsmall + + # "line.col" -> line, as an int + def index2line(index): + return int(float(index)) + + # Look at the leading whitespace in s. + # Return pair (# of leading ws characters, + # effective # of leading blanks after expanding + # tabs to width tabwidth) + + def classifyws(s, tabwidth): + raw = effective = 0 + for ch in s: + if ch == ' ': + raw = raw + 1 + effective = effective + 1 + elif ch == '\t': + raw = raw + 1 + effective = (effective // tabwidth + 1) * tabwidth + else: + break + return raw, effective + + import tokenize + _tokenize = tokenize + del tokenize + + class IndentSearcher: + + # .run() chews over the Text widget, looking for a block opener + # and the stmt following it. Returns a pair, + # (line containing block opener, line containing stmt) + # Either or both may be None. + + def __init__(self, text, tabwidth): + self.text = text + self.tabwidth = tabwidth + self.i = self.finished = 0 + self.blkopenline = self.indentedline = None + + def readline(self): + if self.finished: + return "" + i = self.i = self.i + 1 + mark = `i` + ".0" + if self.text.compare(mark, ">=", "end"): + return "" + return self.text.get(mark, mark + " lineend+1c") + + def tokeneater(self, type, token, start, end, line, + INDENT=_tokenize.INDENT, + NAME=_tokenize.NAME, + OPENERS=('class', 'def', 'for', 'if', 'try', 'while')): + if self.finished: + pass + elif type == NAME and token in OPENERS: + self.blkopenline = line + elif type == INDENT and self.blkopenline: + self.indentedline = line + self.finished = 1 + + def run(self): + save_tabsize = _tokenize.tabsize + _tokenize.tabsize = self.tabwidth + try: + try: + _tokenize.tokenize(self.readline, self.tokeneater) + except _tokenize.TokenError: + # since we cut off the tokenizer early, we can trigger + # spurious errors + pass + finally: + _tokenize.tabsize = save_tabsize + return self.blkopenline, self.indentedline + + ### end autoindent code ### def prepstr(s): From kbk@users.sourceforge.net Sat Sep 14 03:40:19 2002 From: kbk@users.sourceforge.net (Kurt B. Kaiser) Date: Fri, 13 Sep 2002 19:40:19 -0700 Subject: [Idle-dev] CVS: idle EditorWindow.py,1.28,1.29 Message-ID: Update of /cvsroot/idlefork/idle In directory usw-pr-cvs1:/tmp/cvs-serv22406 Modified Files: EditorWindow.py Log Message: MERGE DS_RPC_BRANCH into MAIN EditorWindow.py don't track Py Idle patch 543222 - disable script bindings in shell since it was done differently in MAIN Remove "binding comments" 05 Aug 1.23.2.3 to 1.23.2.4 Remove last dependencies to old config backend 06Aug to 1.23.2.5 Index: EditorWindow.py =================================================================== RCS file: /cvsroot/idlefork/idle/EditorWindow.py,v retrieving revision 1.28 retrieving revision 1.29 diff -C2 -r1.28 -r1.29 *** EditorWindow.py 14 Sep 2002 02:34:23 -0000 1.28 --- EditorWindow.py 14 Sep 2002 02:40:17 -0000 1.29 *************** *** 15,19 **** import ReplaceDialog import PyParse - #from IdleConf import idleconf from configHandler import idleConf import aboutDialog, textView, configDialog --- 15,18 ---- *************** *** 21,80 **** # The default tab setting for a Text widget, in average-width characters. TK_TABWIDTH_DEFAULT = 8 - - # File menu - - #$ event <> - #$ win - #$ unix - - #$ event <> - #$ win - #$ unix - - #$ event <> - - #$ event <> - - #$ unix - #$ unix - #$ win - - # Edit menu - - #$ event <> - #$ win - #$ unix - - #$ event <> - #$ win - #$ unix - - #$ event <> - #$ win - #$ unix - - #$ event <> - #$ win - #$ unix - - # Help menu - - #$ event <> - #$ win - #$ unix - - #$ event <> - - # Events without menu entries - - #$ event <> - #$ win - - #$ event <> - #$ win - #$ unix - - #$ event <> - #$ unix class EditorWindow: --- 20,23 ---- From kbk@users.sourceforge.net Sat Sep 14 03:46:22 2002 From: kbk@users.sourceforge.net (Kurt B. Kaiser) Date: Fri, 13 Sep 2002 19:46:22 -0700 Subject: [Idle-dev] CVS: idle ParenMatch.py,1.4,1.5 Message-ID: Update of /cvsroot/idlefork/idle In directory usw-pr-cvs1:/tmp/cvs-serv23575 Modified Files: ParenMatch.py Log Message: MERGE DS_RPC_BRANCH into MAIN ParenMatch.py Remove last dependencies to old config backend 06Aug Index: ParenMatch.py =================================================================== RCS file: /cvsroot/idlefork/idle/ParenMatch.py,v retrieving revision 1.4 retrieving revision 1.5 diff -C2 -r1.4 -r1.5 *** ParenMatch.py 19 Jan 2002 10:41:51 -0000 1.4 --- ParenMatch.py 14 Sep 2002 02:46:19 -0000 1.5 *************** *** 15,19 **** import PyParse from AutoIndent import AutoIndent, index2line ! from IdleConf import idleconf class ParenMatch: --- 15,19 ---- import PyParse from AutoIndent import AutoIndent, index2line ! from configHandler import idleConf class ParenMatch: *************** *** 45,54 **** """ menudefs = [] ! iconf = idleconf.getsection('ParenMatch') ! STYLE = iconf.getdef('style', 'default') ! FLASH_DELAY = iconf.getint('flash-delay') ! HILITE_CONFIG = iconf.getcolor('hilite') ! BELL = iconf.getboolean('bell') ! del iconf def __init__(self, editwin): --- 45,55 ---- """ menudefs = [] ! STYLE = idleConf.GetOption('extensions','ParenMatch','style', ! default='expression') ! FLASH_DELAY = idleConf.GetOption('extensions','ParenMatch','flash-delay', ! type='int',default=500) ! HILITE_CONFIG = idleConf.GetHighlight(idleConf.CurrentTheme(),'hilite') ! BELL = idleConf.GetOption('extensions','ParenMatch','bell', ! type='bool',default=1) def __init__(self, editwin): From kbk@users.sourceforge.net Sat Sep 14 03:50:58 2002 From: kbk@users.sourceforge.net (Kurt B. Kaiser) Date: Fri, 13 Sep 2002 19:50:58 -0700 Subject: [Idle-dev] CVS: idle PyShell.py,1.23,1.24 Message-ID: Update of /cvsroot/idlefork/idle In directory usw-pr-cvs1:/tmp/cvs-serv24082 Modified Files: PyShell.py Log Message: MERGE DS_RPC_BRANCH into MAIN PyShell.py don't track Py Idle patch 543222 - disable script bindings in shell since it was done differently in MAIN Remove "binding comments" 05 Aug 1.13.2.2 to 1.13.2.3 Index: PyShell.py =================================================================== RCS file: /cvsroot/idlefork/idle/PyShell.py,v retrieving revision 1.23 retrieving revision 1.24 diff -C2 -r1.23 -r1.24 *** PyShell.py 5 Sep 2002 02:31:20 -0000 1.23 --- PyShell.py 14 Sep 2002 02:50:56 -0000 1.24 *************** *** 56,93 **** linecache.checkcache = linecache_checkcache - - # Note: <> event is defined in AutoIndent.py - - #$ event <> - #$ win - #$ unix - - #$ event <> - #$ win - #$ win - #$ unix - #$ unix - - #$ event <> - #$ win - #$ unix - - #$ event <> - #$ win - #$ unix - - #$ event <> - #$ win - #$ unix - - #$ event <> - #$ win - #$ unix - - #$ event <> - - #$ event <> - - class PyShellEditorWindow(EditorWindow): "Regular text edit window when a shell is present" --- 56,59 ---- *************** *** 497,502 **** __builtin__.quit = __builtin__.exit = "To exit, type Ctrl-D." ! self.auto = self.extensions["AutoIndent"] # Required extension ! self.auto.config(usetabs=1, indentwidth=8, context_use_ps1=1) text = self.text --- 463,467 ---- __builtin__.quit = __builtin__.exit = "To exit, type Ctrl-D." ! self.config(usetabs=1, indentwidth=8, context_use_ps1=1) text = self.text *************** *** 628,632 **** self.interp = None self.console = None - self.auto = None self.flist.pyshell = None self.history = None --- 593,596 ---- *************** *** 737,741 **** self.text.see("insert") else: ! self.auto.auto_indent(event) return "break" --- 701,705 ---- self.text.see("insert") else: ! self.auto_indent(event) return "break" *************** *** 777,781 **** # insert a newline right at the insert point if self.text.compare("insert", "<", "end-1c linestart"): ! self.auto.auto_indent(event) return "break" # We're in the last line; append a newline and submit it --- 741,745 ---- # insert a newline right at the insert point if self.text.compare("insert", "<", "end-1c linestart"): ! self.auto_indent(event) return "break" # We're in the last line; append a newline and submit it *************** *** 785,789 **** self.text.see("insert") else: ! self.auto.auto_indent(event) self.text.tag_add("stdin", "iomark", "end-1c") self.text.update_idletasks() --- 749,753 ---- self.text.see("insert") else: ! self.auto_indent(event) self.text.tag_add("stdin", "iomark", "end-1c") self.text.update_idletasks() From kbk@users.sourceforge.net Sat Sep 14 03:53:07 2002 From: kbk@users.sourceforge.net (Kurt B. Kaiser) Date: Fri, 13 Sep 2002 19:53:07 -0700 Subject: [Idle-dev] CVS: idle ReplaceDialog.py,1.3,1.4 Message-ID: Update of /cvsroot/idlefork/idle In directory usw-pr-cvs1:/tmp/cvs-serv24710 Modified Files: ReplaceDialog.py Log Message: MERGE DS_RPC_BRANCH into MAIN ReplaceDialog (missed a change Py Idle 04Apr2002, Booleans, pick up later) track Py Idle: GvR drops 1.5.2 re support 24 Jul Index: ReplaceDialog.py =================================================================== RCS file: /cvsroot/idlefork/idle/ReplaceDialog.py,v retrieving revision 1.3 retrieving revision 1.4 diff -C2 -r1.3 -r1.4 *** ReplaceDialog.py 12 Jul 2001 06:54:16 -0000 1.3 --- ReplaceDialog.py 14 Sep 2002 02:53:05 -0000 1.4 *************** *** 91,95 **** chars = text.get("%d.0" % line, "%d.0" % (line+1)) orig = m.group() ! new = self._expand(m, repl) i, j = m.span() first = "%d.%d" % (line, i) --- 91,95 ---- chars = text.get("%d.0" % line, "%d.0" % (line+1)) orig = m.group() ! new = m.expand(repl) i, j = m.span() first = "%d.%d" % (line, i) *************** *** 143,147 **** if not prog: return 0 ! new = self._expand(m, self.replvar.get()) text.mark_set("insert", first) text.undo_block_start() --- 143,147 ---- if not prog: return 0 ! new = m.expand(self.replvar.get()) text.mark_set("insert", first) text.undo_block_start() *************** *** 154,173 **** self.ok = 0 return 1 - - def _expand(self, m, template): - # XXX This code depends on internals of the regular expression - # engine! There's no standard API to do a substitution when you - # have already found the match. One should be added. - # The solution here is designed to be backwards compatible - # with previous Python versions, e.g. 1.5.2. - # XXX This dynamic test should be done only once. - if getattr(re, "engine", "pre") == "pre": - return re.pcre_expand(m, template) - else: # sre - # XXX This import should be avoidable... - import sre_parse - # XXX This parses the template over and over... - ptemplate = sre_parse.parse_template(template, m.re) - return sre_parse.expand_template(ptemplate, m) def show_hit(self, first, last): --- 154,157 ---- From kbk@users.sourceforge.net Sat Sep 14 03:56:07 2002 From: kbk@users.sourceforge.net (Kurt B. Kaiser) Date: Fri, 13 Sep 2002 19:56:07 -0700 Subject: [Idle-dev] CVS: idle ToolTip.py,1.3,1.4 Message-ID: Update of /cvsroot/idlefork/idle In directory usw-pr-cvs1:/tmp/cvs-serv25296 Modified Files: ToolTip.py Log Message: MERGE DS_RPC_BRANCH into MAIN ToolTip.py cleanup 05Aug Index: ToolTip.py =================================================================== RCS file: /cvsroot/idlefork/idle/ToolTip.py,v retrieving revision 1.3 retrieving revision 1.4 diff -C2 -r1.3 -r1.4 *** ToolTip.py 14 Jul 2001 01:14:09 -0000 1.3 --- ToolTip.py 14 Sep 2002 02:56:04 -0000 1.4 *************** *** 1,2 **** --- 1,5 ---- + # general purpose 'tooltip' routines - currently unused in idlefork + # (although the 'calltips' extension is partly based on this code) + # may be useful for some purposes in (or almost in ;) the current project scope # Ideas gleaned from PySol From kbk@users.sourceforge.net Sat Sep 14 03:58:09 2002 From: kbk@users.sourceforge.net (Kurt B. Kaiser) Date: Fri, 13 Sep 2002 19:58:09 -0700 Subject: [Idle-dev] CVS: idle configDialog.py,1.46,1.47 Message-ID: Update of /cvsroot/idlefork/idle In directory usw-pr-cvs1:/tmp/cvs-serv25650 Modified Files: configDialog.py Log Message: MERGE DS_RPC_BRANCH into MAIN: configDialog.py AutoIndent merged 21Jul Index: configDialog.py =================================================================== RCS file: /cvsroot/idlefork/idle/configDialog.py,v retrieving revision 1.46 retrieving revision 1.47 diff -C2 -r1.46 -r1.47 *** configDialog.py 27 Mar 2002 08:40:46 -0000 1.46 --- configDialog.py 14 Sep 2002 02:58:07 -0000 1.47 *************** *** 126,132 **** text='Choose indentation size :') labelSpaceNumTitle=Label(frameIndentSize,justify=LEFT, ! text='when tab key inserts spaces,\nspaces per indent') self.scaleSpaceNum=Scale(frameIndentSize,variable=self.spaceNum, ! orient='horizontal',tickinterval=2,from_=2,to=10) #labeltabColsTitle=Label(frameIndentSize,justify=LEFT, # text='when tab key inserts tabs,\ncolumns per tab') --- 126,132 ---- text='Choose indentation size :') labelSpaceNumTitle=Label(frameIndentSize,justify=LEFT, ! text='indent width') self.scaleSpaceNum=Scale(frameIndentSize,variable=self.spaceNum, ! orient='horizontal',tickinterval=2,from_=2,to=16) #labeltabColsTitle=Label(frameIndentSize,justify=LEFT, # text='when tab key inserts tabs,\ncolumns per tab') From kbk@users.sourceforge.net Sat Sep 14 04:15:08 2002 From: kbk@users.sourceforge.net (Kurt B. Kaiser) Date: Fri, 13 Sep 2002 20:15:08 -0700 Subject: [Idle-dev] CVS: idle config-extensions.def,1.6,1.7 Message-ID: Update of /cvsroot/idlefork/idle In directory usw-pr-cvs1:/tmp/cvs-serv30003 Modified Files: config-extensions.def Log Message: MERGE DS_RPC_BRANCH into MAIN: config-extensions.def AutoIndent merged 21Jul Index: config-extensions.def =================================================================== RCS file: /cvsroot/idlefork/idle/config-extensions.def,v retrieving revision 1.6 retrieving revision 1.7 diff -C2 -r1.6 -r1.7 *** config-extensions.def 12 Jun 2002 03:28:57 -0000 1.6 --- config-extensions.def 14 Sep 2002 03:15:06 -0000 1.7 *************** *** 18,36 **** format-paragraph= - [AutoIndent] - enable=1 - [AutoIndent_cfgBindings] - smart-backspace= - newline-and-indent= - smart-indent= - indent-region= - dedent-region= - comment-region= - uncomment-region= - tabify-region= - untabify-region= - toggle-tabs= - change-indentwidth= - [AutoExpand] enable=1 --- 18,21 ---- From kbk@users.sourceforge.net Sat Sep 14 04:17:04 2002 From: kbk@users.sourceforge.net (Kurt B. Kaiser) Date: Fri, 13 Sep 2002 20:17:04 -0700 Subject: [Idle-dev] CVS: idle configHandler.py,1.23,1.24 Message-ID: Update of /cvsroot/idlefork/idle In directory usw-pr-cvs1:/tmp/cvs-serv30392 Modified Files: configHandler.py Log Message: MERGE DS_RPC_BRANCH into MAIN configHandler.py AutoIndent merged 21Jul Index: configHandler.py =================================================================== RCS file: /cvsroot/idlefork/idle/configHandler.py,v retrieving revision 1.23 retrieving revision 1.24 diff -C2 -r1.23 -r1.24 *** configHandler.py 11 Jun 2002 04:45:32 -0000 1.23 --- configHandler.py 14 Sep 2002 03:17:01 -0000 1.24 *************** *** 522,526 **** '<>': [''], '<>': [''], ! '<>': [''] } if keySetName: for event in keyBindings.keys(): --- 522,538 ---- '<>': [''], '<>': [''], ! '<>': [''], ! '<>': [''], ! '<>': [' '], ! '<>': [''], ! '<>': [''], ! '<>': [''], ! '<>': [''], ! '<>': [''], ! '<>': [''], ! '<>': [''], ! '<>': [''], ! '<>': [''] ! } if keySetName: for event in keyBindings.keys(): From kbk@users.sourceforge.net Sat Sep 14 04:18:45 2002 From: kbk@users.sourceforge.net (Kurt B. Kaiser) Date: Fri, 13 Sep 2002 20:18:45 -0700 Subject: [Idle-dev] CVS: idle config-keys.def,1.10,1.11 Message-ID: Update of /cvsroot/idlefork/idle In directory usw-pr-cvs1:/tmp/cvs-serv30813 Modified Files: config-keys.def Log Message: MERGE DS_RPC_BRANCH into MAIN: config-keys.def AutoIndent merged 21Jul Index: config-keys.def =================================================================== RCS file: /cvsroot/idlefork/idle/config-keys.def,v retrieving revision 1.10 retrieving revision 1.11 diff -C2 -r1.10 -r1.11 *** config-keys.def 11 Jun 2002 04:45:34 -0000 1.10 --- config-keys.def 14 Sep 2002 03:18:43 -0000 1.11 *************** *** 42,45 **** --- 42,56 ---- replace= goto-line= + smart-backspace= + newline-and-indent= + smart-indent= + indent-region= + dedent-region= + comment-region= + uncomment-region= + tabify-region= + untabify-region= + toggle-tabs= + change-indentwidth= [IDLE Classic Unix] *************** *** 78,79 **** --- 89,101 ---- replace= goto-line= + smart-backspace= + newline-and-indent= + smart-indent= + indent-region= + dedent-region= + comment-region= + uncomment-region= + tabify-region= + untabify-region= + toggle-tabs= + change-indentwidth= From kbk@users.sourceforge.net Sat Sep 14 04:30:49 2002 From: kbk@users.sourceforge.net (Kurt B. Kaiser) Date: Fri, 13 Sep 2002 20:30:49 -0700 Subject: [Idle-dev] CVS: idle AutoIndent.py,1.5,NONE IdleConf.py,1.4,NONE MultiScrolledLists.py,1.3,NONE Separator.py,1.3,NONE config-unix.txt,1.2,NONE config-win.txt,1.2,NONE config.txt,1.5,NONE eventparse.py,1.2,NONE keydefs.py,1.3,NONE Message-ID: Update of /cvsroot/idlefork/idle In directory usw-pr-cvs1:/tmp/cvs-serv566 Removed Files: AutoIndent.py IdleConf.py MultiScrolledLists.py Separator.py config-unix.txt config-win.txt config.txt eventparse.py keydefs.py Log Message: MERGE DS_RPC_BRANCH into MAIN Removed Files: AutoIndent.py IdleConf.py MultiScrolledLists.py Separator.py config-unix.txt config-win.txt config.txt eventparse.py keydefs.py --- AutoIndent.py DELETED --- --- IdleConf.py DELETED --- --- MultiScrolledLists.py DELETED --- --- Separator.py DELETED --- --- config-unix.txt DELETED --- --- config-win.txt DELETED --- --- config.txt DELETED --- --- eventparse.py DELETED --- --- keydefs.py DELETED --- From kbk@shore.net Sat Sep 14 05:16:27 2002 From: kbk@shore.net (Kurt B. Kaiser) Date: 14 Sep 2002 00:16:27 -0400 Subject: [Idle-dev] Summary of DS_RPC_BRANCH Merge to MAIN Message-ID: Modified modules/files (since the DS_RPC branch was created) Bindings AutoIndent merged 21Jul cleanup and remove references to config backend 06Aug CallTips track Py Idle loewis: Use ascii_letters to avoid UnicodeErrors 06Aug EditorWindow AutoIndent merged 21Jul Delete debug messages 21Jul track Py Idle patch 543222 - disable script bindings in shell - NO!! 24Jul This was 1.23.2.3, use 1.23.2.2 and skip over Remove "binding comments" 05 Aug 1.23.2.3 to 1.23.2.4 Remove last dependencies to old config backend 06Aug to 1.23.2.5 ParenMatch Remove last dependencies to old config backend 06Aug PyShell track Py Idle patch 543222 - disable script bindings in shell - NO!! 24Jul This was 1.13.2.2, use 1.13.2.1 and skip over Remove "binding comments" 05 Aug 1.13.2.2 to 1.13.2.3 ReplaceDialog (missed a change Py Idle 04Apr2002, Booleans) track Py Idle: GvR drops 1.5.2 re support 24 Jul ScriptBinding track Py Idle patch 543222 - disable script bindings in shell - NO!! 24Jul This was 1.4.2.1, use 1.4 and skip over ToolTip cleanup 05Aug configDialog 21 Jul AutoIndent merged 21Jul config-extensions.def AutoIndent merged 21Jul configHandler AutoIndent merged 21Jul config-keys.def AutoIndent merged 21Jul ================== Deleted modules/files: AutoIndent 21Jul FrameViewer 05Aug (previously removed from MAIN) IdleConf 06Aug MultiScrolledLists 05Aug RemoteInterp 05 Aug (previously removed from MAIN) Separator 05Aug config-unix.txt 06Aug config-win.txt 06Aug config.txt 06 Aug eventparse 05Aug keydefs 06Aug From kbk@users.sourceforge.net Sat Sep 14 05:24:45 2002 From: kbk@users.sourceforge.net (Kurt B. Kaiser) Date: Fri, 13 Sep 2002 21:24:45 -0700 Subject: [Idle-dev] CVS: idle idlever.py,1.5,1.6 Message-ID: Update of /cvsroot/idlefork/idle In directory usw-pr-cvs1:/tmp/cvs-serv12811 Modified Files: idlever.py Log Message: Bump to reflect final cleanup of Config system and first pass GRPC completed Index: idlever.py =================================================================== RCS file: /cvsroot/idlefork/idle/idlever.py,v retrieving revision 1.5 retrieving revision 1.6 diff -C2 -r1.5 -r1.6 *** idlever.py 31 Jul 2001 07:00:39 -0000 1.5 --- idlever.py 14 Sep 2002 04:24:43 -0000 1.6 *************** *** 1 **** ! IDLE_VERSION = "0.8.2" --- 1 ---- ! IDLE_VERSION = "0.8.9" From kbk@shore.net Sat Sep 14 05:36:49 2002 From: kbk@shore.net (Kurt B. Kaiser) Date: 14 Sep 2002 00:36:49 -0400 Subject: [Idle-dev] ANNOUNCE -- Developers Switch to MAIN Message-ID: The DS_RPC_BRANCH has been merged to MAIN. In other words, the good work that Stephen Gava has been doing over there on the Configuration System since the branch split off has now been incorporated in the CVS MAIN trunk, along with some Python Idle tracking changes. I'd recommend that all developers switch to MAIN at this time. cvs up -A rm *.pyc I will be merging some additional Python Idle tracking changes over the next few days so please update when you see them go by on the list. Please submit unresolved bugs to the Sourceforge Bug Tracker and field generated patches to the Patch Tracker. KBK From kbk@users.sourceforge.net Sun Sep 15 00:25:33 2002 From: kbk@users.sourceforge.net (Kurt B. Kaiser) Date: Sat, 14 Sep 2002 16:25:33 -0700 Subject: [Idle-dev] CVS: idle - Imported sources Message-ID: Update of /cvsroot/idlefork/idle In directory usw-pr-cvs1:/tmp/cvs-serv28200 Log Message: Import the 2002 Sep 13 23:59 GMT version of Python CVS Idle on the existing 1.1.3 vendor branch named py-cvs-vendor-branch. Release tag is py-cvs-2002_09_13. Status: Vendor Tag: py-cvs-vendor-branch Release Tags: py-cvs-2002_09_13 C idle/AutoExpand.py C idle/AutoIndent.py C idle/Bindings.py C idle/CallTipWindow.py C idle/CallTips.py U idle/ChangeLog C idle/ClassBrowser.py C idle/ColorDelegator.py C idle/Debugger.py U idle/Delegator.py C idle/EditorWindow.py U idle/FileList.py C idle/FormatParagraph.py U idle/FrameViewer.py C idle/GrepDialog.py C idle/IOBinding.py U idle/IdleConf.py C idle/IdleHistory.py C idle/MultiScrolledLists.py U idle/MultiStatusBar.py U idle/NEWS.txt C idle/ObjectBrowser.py C idle/OldStackViewer.py C idle/OutputWindow.py C idle/ParenMatch.py U idle/PathBrowser.py U idle/Percolator.py C idle/PyParse.py C idle/PyShell.py U idle/README.txt C idle/RemoteInterp.py C idle/ReplaceDialog.py C idle/ScriptBinding.py U idle/ScrolledList.py U idle/SearchBinding.py C idle/SearchDialog.py C idle/SearchDialogBase.py C idle/SearchEngine.py U idle/Separator.py C idle/StackViewer.py U idle/TODO.txt C idle/ToolTip.py C idle/TreeWidget.py C idle/UndoDelegator.py U idle/WidgetRedirector.py U idle/WindowList.py U idle/ZoomHeight.py U idle/__init__.py N idle/config-mac.txt C idle/config-unix.txt C idle/config-win.txt U idle/config.txt C idle/eventparse.py U idle/extend.txt C idle/help.txt U idle/idle U idle/idle.bat U idle/idle.py U idle/idle.pyw U idle/idlever.py C idle/keydefs.py C idle/setup.py U idle/testcode.py U idle/Icons/folder.gif C idle/Icons/minusnode.gif U idle/Icons/openfolder.gif U idle/Icons/plusnode.gif U idle/Icons/python.gif U idle/Icons/tk.gif 37 conflicts created by this import. Use the following command to help the merge: cvs checkout -jpy-cvs-vendor-branch:yesterday -jpy-cvs-vendor-branch idle ***** Bogus filespec: - ***** Bogus filespec: Imported ***** Bogus filespec: sources From kbk@users.sourceforge.net Sun Sep 15 21:50:04 2002 From: kbk@users.sourceforge.net (Kurt B. Kaiser) Date: Sun, 15 Sep 2002 13:50:04 -0700 Subject: [Idle-dev] CVS: idle AutoExpand.py,1.4,1.5 Message-ID: Update of /cvsroot/idlefork/idle In directory usw-pr-cvs1:/tmp/cvs-serv18622 Modified Files: AutoExpand.py Log Message: Merge Py Idle's Rev 1.5 Use string.ascii_letters instead of string.letters (SF bug #226706) Index: AutoExpand.py =================================================================== RCS file: /cvsroot/idlefork/idle/AutoExpand.py,v retrieving revision 1.4 retrieving revision 1.5 diff -C2 -r1.4 -r1.5 *** AutoExpand.py 19 Jan 2002 10:36:54 -0000 1.4 --- AutoExpand.py 15 Sep 2002 20:50:02 -0000 1.5 *************** *** 14,18 **** ] ! wordchars = string.letters + string.digits + "_" def __init__(self, editwin): --- 14,18 ---- ] ! wordchars = string.ascii_letters + string.digits + "_" def __init__(self, editwin): From kbk@users.sourceforge.net Sun Sep 15 22:31:32 2002 From: kbk@users.sourceforge.net (Kurt B. Kaiser) Date: Sun, 15 Sep 2002 14:31:32 -0700 Subject: [Idle-dev] CVS: idle EditorWindow.py,1.29,1.30 Message-ID: Update of /cvsroot/idlefork/idle In directory usw-pr-cvs1:/tmp/cvs-serv29560 Modified Files: EditorWindow.py Log Message: Merge Py Idle's changes to AutoIndent.py into EditorWindow.py since EditorWindow has incorporated AutoIndent Rev 1.17 classifyws(): Fix a "/" to work under -Qnew (as well as without it). Bugfix candidate! Rev 1.18 (Already merged) Rev 1.19 smart_backspace_event(): remove now-pointless int() call. Bugfix candidate: the current state of AutoIdent.py should be in 2.2.1. Rev 1.20 Apply diff2.txt from SF patch http://www.python.org/sf/572113 (with one small bugfix in bgen/bgen/scantools.py) This replaces string module functions with string methods for the stuff in the Tools directory. Several uses of string.letters etc. are still remaining. Index: EditorWindow.py =================================================================== RCS file: /cvsroot/idlefork/idle/EditorWindow.py,v retrieving revision 1.29 retrieving revision 1.30 diff -C2 -r1.29 -r1.30 *** EditorWindow.py 14 Sep 2002 02:40:17 -0000 1.29 --- EditorWindow.py 15 Sep 2002 21:31:30 -0000 1.30 *************** *** 1,5 **** import sys import os - import string import re import imp --- 1,4 ---- *************** *** 914,919 **** # Ick. It may require *inserting* spaces if we back up over a # tab character! This is written to be clear, not fast. ! expand, tabwidth = string.expandtabs, self.tabwidth ! have = len(expand(chars, tabwidth)) assert have > 0 want = ((have - 1) // self.indentwidth) * self.indentwidth --- 913,918 ---- # Ick. It may require *inserting* spaces if we back up over a # tab character! This is written to be clear, not fast. ! tabwidth = self.tabwidth ! have = len(chars.expandtabs(tabwidth)) assert have > 0 want = ((have - 1) // self.indentwidth) * self.indentwidth *************** *** 922,926 **** chars = chars[:-1] ncharsdeleted = ncharsdeleted + 1 ! have = len(expand(chars, tabwidth)) if have <= want or chars[-1] not in " \t": break --- 921,925 ---- chars = chars[:-1] ncharsdeleted = ncharsdeleted + 1 ! have = len(chars.expandtabs(tabwidth)) if have <= want or chars[-1] not in " \t": break *************** *** 956,961 **** pad = '\t' else: ! effective = len(string.expandtabs(prefix, ! self.tabwidth)) n = self.indentwidth pad = ' ' * (n - effective % n) --- 955,959 ---- pad = '\t' else: ! effective = len(prefix.expandtabs(self.tabwidth)) n = self.indentwidth pad = ' ' * (n - effective % n) *************** *** 1122,1126 **** tabwidth = self._asktabwidth() for pos in range(len(lines)): ! lines[pos] = string.expandtabs(lines[pos], tabwidth) self.set_region(head, tail, chars, lines) --- 1120,1124 ---- tabwidth = self._asktabwidth() for pos in range(len(lines)): ! lines[pos] = lines[pos].expandtabs(tabwidth) self.set_region(head, tail, chars, lines) *************** *** 1163,1172 **** tail = text.index("insert lineend +1c") chars = text.get(head, tail) ! lines = string.split(chars, "\n") return head, tail, chars, lines def set_region(self, head, tail, chars, lines): text = self.text ! newchars = string.join(lines, "\n") if newchars == chars: text.bell() --- 1161,1170 ---- tail = text.index("insert lineend +1c") chars = text.get(head, tail) ! lines = chars.split("\n") return head, tail, chars, lines def set_region(self, head, tail, chars, lines): text = self.text ! newchars = "\n".join(lines) if newchars == chars: text.bell() From kbk@users.sourceforge.net Sun Sep 15 22:38:22 2002 From: kbk@users.sourceforge.net (Kurt B. Kaiser) Date: Sun, 15 Sep 2002 14:38:22 -0700 Subject: [Idle-dev] CVS: idle Bindings.py,1.11,1.12 Message-ID: Update of /cvsroot/idlefork/idle In directory usw-pr-cvs1:/tmp/cvs-serv32736 Modified Files: Bindings.py Log Message: Merge Py Idle's Rev 1.16 (string methods) Index: Bindings.py =================================================================== RCS file: /cvsroot/idlefork/idle/Bindings.py,v retrieving revision 1.11 retrieving revision 1.12 diff -C2 -r1.11 -r1.12 *** Bindings.py 14 Sep 2002 00:50:44 -0000 1.11 --- Bindings.py 15 Sep 2002 21:38:20 -0000 1.12 *************** *** 7,11 **** import sys - import string from configHandler import idleConf --- 7,10 ---- From kbk@users.sourceforge.net Sun Sep 15 22:43:16 2002 From: kbk@users.sourceforge.net (Kurt B. Kaiser) Date: Sun, 15 Sep 2002 14:43:16 -0700 Subject: [Idle-dev] CVS: idle CallTipWindow.py,1.3,1.4 Message-ID: Update of /cvsroot/idlefork/idle In directory usw-pr-cvs1:/tmp/cvs-serv1427 Modified Files: CallTipWindow.py Log Message: Merge Py Idle changes Rev 1.4 SF bug 546078: IDLE calltips cause application error. Assorted crashes on Windows and Linux when trying to display a very long calltip, most likely a Tk bug. Wormed around by clamping the calltip display to a maximum of 79 characters (why 79? why not ...). Bugfix candidate, for all Python releases. Rev 1.5 Remove unnecessary imports Index: CallTipWindow.py =================================================================== RCS file: /cvsroot/idlefork/idle/CallTipWindow.py,v retrieving revision 1.3 retrieving revision 1.4 diff -C2 -r1.3 -r1.4 *** CallTipWindow.py 12 Jul 2001 22:26:44 -0000 1.3 --- CallTipWindow.py 15 Sep 2002 21:43:13 -0000 1.4 *************** *** 3,7 **** # Used by the CallTips IDLE extension. - import os from Tkinter import * --- 3,6 ---- *************** *** 15,19 **** --- 14,24 ---- def showtip(self, text): + # SF bug 546078: IDLE calltips cause application error. + # There were crashes on various Windows flavors, and even a + # crashing X server on Linux, with very long calltips. + if len(text) >= 79: + text = text[:75] + ' ...' self.text = text + if self.tipwindow or not self.text: return From kbk@users.sourceforge.net Sun Sep 15 23:03:00 2002 From: kbk@users.sourceforge.net (Kurt B. Kaiser) Date: Sun, 15 Sep 2002 15:03:00 -0700 Subject: [Idle-dev] CVS: idle CallTips.py,1.5,1.6 Message-ID: Update of /cvsroot/idlefork/idle In directory usw-pr-cvs1:/tmp/cvs-serv5999 Modified Files: CallTips.py Log Message: Merge Py Idle changes Rev 1.9 Improve handling of docstrings. I had feared this was a case of introspection incompatibility, but in fact it's just that calltips always gave up on a docstring that started with a newline (but didn't realize they were giving up ). Rev 1.10 (already merged) Rev 1.11 (whitespace normalization, skip this time) Rev 1.12 Remove unnecessary imports Index: CallTips.py =================================================================== RCS file: /cvsroot/idlefork/idle/CallTips.py,v retrieving revision 1.5 retrieving revision 1.6 diff -C2 -r1.5 -r1.6 *** CallTips.py 14 Sep 2002 00:55:21 -0000 1.5 --- CallTips.py 15 Sep 2002 22:02:58 -0000 1.6 *************** *** 3,7 **** import string - import sys import types --- 3,6 ---- *************** *** 129,142 **** if fob.func_code.co_flags & 0x8: items.append("***") ! argText = string.join(items , ", ") argText = "(%s)" % argText except: pass # See if we can use the docstring ! if hasattr(ob, "__doc__") and ob.__doc__: ! pos = string.find(ob.__doc__, "\n") ! if pos<0 or pos>70: pos=70 ! if argText: argText = argText + "\n" ! argText = argText + ob.__doc__[:pos] return argText --- 128,146 ---- if fob.func_code.co_flags & 0x8: items.append("***") ! argText = ", ".join(items) argText = "(%s)" % argText except: pass # See if we can use the docstring ! doc = getattr(ob, "__doc__", "") ! if doc: ! while doc[:1] in " \t\n": ! doc = doc[1:] ! pos = doc.find("\n") ! if pos < 0 or pos > 70: ! pos = 70 ! if argText: ! argText += "\n" ! argText += doc[:pos] return argText From kbk@users.sourceforge.net Sun Sep 15 23:06:49 2002 From: kbk@users.sourceforge.net (Kurt B. Kaiser) Date: Sun, 15 Sep 2002 15:06:49 -0700 Subject: [Idle-dev] CVS: idle ClassBrowser.py,1.3,1.4 Message-ID: Update of /cvsroot/idlefork/idle In directory usw-pr-cvs1:/tmp/cvs-serv7583 Modified Files: ClassBrowser.py Log Message: Merge Py Idle changes Rev 1.13 (string methods) Index: ClassBrowser.py =================================================================== RCS file: /cvsroot/idlefork/idle/ClassBrowser.py,v retrieving revision 1.3 retrieving revision 1.4 diff -C2 -r1.3 -r1.4 *** ClassBrowser.py 12 Jul 2001 23:54:20 -0000 1.3 --- ClassBrowser.py 15 Sep 2002 22:06:47 -0000 1.4 *************** *** 13,17 **** import os import sys - import string import pyclbr --- 13,16 ---- *************** *** 118,122 **** sname = "%s.%s" % (sup.module, sname) supers.append(sname) ! s = s + "(%s)" % string.join(supers, ", ") items.append((cl.lineno, s)) self.classes[s] = cl --- 117,121 ---- sname = "%s.%s" % (sup.module, sname) supers.append(sname) ! s = s + "(%s)" % ", ".join(supers) items.append((cl.lineno, s)) self.classes[s] = cl From kbk@users.sourceforge.net Sun Sep 15 23:09:18 2002 From: kbk@users.sourceforge.net (Kurt B. Kaiser) Date: Sun, 15 Sep 2002 15:09:18 -0700 Subject: [Idle-dev] CVS: idle ColorDelegator.py,1.7,1.8 Message-ID: Update of /cvsroot/idlefork/idle In directory usw-pr-cvs1:/tmp/cvs-serv8372 Modified Files: ColorDelegator.py Log Message: Merge Py Idle changes Rev 1.13 (string methods) Index: ColorDelegator.py =================================================================== RCS file: /cvsroot/idlefork/idle/ColorDelegator.py,v retrieving revision 1.7 retrieving revision 1.8 diff -C2 -r1.7 -r1.8 *** ColorDelegator.py 2 Mar 2002 07:14:14 -0000 1.7 --- ColorDelegator.py 15 Sep 2002 22:09:16 -0000 1.8 *************** *** 1,4 **** import time - import string import re import keyword --- 1,3 ---- *************** *** 15,19 **** def any(name, list): ! return "(?P<%s>" % name + string.join(list, "|") + ")" def make_pat(): --- 14,18 ---- def any(name, list): ! return "(?P<%s>" % name + "|".join(list) + ")" def make_pat(): From kbk@shore.net Sun Sep 15 23:17:07 2002 From: kbk@shore.net (Kurt B. Kaiser) Date: 15 Sep 2002 18:17:07 -0400 Subject: [Idle-dev] ANNOUNCE -- Merging Python Idle, CVS is Unstable Message-ID: I'm merging the changes made to Python Idle into Idlefork. Since this is being done on a file by file basis, there may be mutually incompatible modules checked in until I'm finished. I'd recommend not syncing up to CVS until this is finished if you expect to execute the result :) I expect it will take three days. I'll announce when the merge is completed. Thanks, KBK From kbk@users.sourceforge.net Mon Sep 16 02:06:54 2002 From: kbk@users.sourceforge.net (Kurt B. Kaiser) Date: Sun, 15 Sep 2002 18:06:54 -0700 Subject: [Idle-dev] CVS: idle Debugger.py,1.12,1.13 Message-ID: Update of /cvsroot/idlefork/idle In directory usw-pr-cvs1:/tmp/cvs-serv12658 Modified Files: Debugger.py Log Message: Merge Py Idle changes Rev 1.16 (skip. The Edward K. Ream breakpoint fix has been added to bdb.py and idlefork Debugger.py no longer overrides Bdb.set_break() ) Rev 1.17 Remove unnecessary imports Index: Debugger.py =================================================================== RCS file: /cvsroot/idlefork/idle/Debugger.py,v retrieving revision 1.12 retrieving revision 1.13 diff -C2 -r1.12 -r1.13 *** Debugger.py 6 Jul 2002 04:22:25 -0000 1.12 --- Debugger.py 16 Sep 2002 01:06:52 -0000 1.13 *************** *** 2,6 **** import bdb import types - import traceback from Tkinter import * from WindowList import ListedToplevel --- 2,5 ---- From kbk@users.sourceforge.net Mon Sep 16 03:13:17 2002 From: kbk@users.sourceforge.net (Kurt B. Kaiser) Date: Sun, 15 Sep 2002 19:13:17 -0700 Subject: [Idle-dev] CVS: idle EditorWindow.py,1.30,1.31 Message-ID: Update of /cvsroot/idlefork/idle In directory usw-pr-cvs1:/tmp/cvs-serv22220 Modified Files: EditorWindow.py Log Message: Merge Py Idle changes: Rev 1.39 GvR Properly fix SF bug #507298 (Gregor Lingl): shellpython2.2 -Qnew smart indent error Use // where int division is intended. (This breaks IDLE for use with previous Python versions -- I don't care.) Rev 1.40 tim_one Convert a pile of obvious "yes/no" functions to return bool. Rev 1.41 foffani/loewis (already merged) - MS html help Rev 1.42 (skip, done differently in Idlefork) Rev 1.43 tzot/rhettinger Extended IDLE's open module menu item to handle hierarchical module names. Will look at doing something similar in import.c so that the effort won't have to be repeated elsewhere. Closes SF patch 600152. Rev 1.44 doerwalter (string methods) Index: EditorWindow.py =================================================================== RCS file: /cvsroot/idlefork/idle/EditorWindow.py,v retrieving revision 1.30 retrieving revision 1.31 diff -C2 -r1.30 -r1.31 *** EditorWindow.py 15 Sep 2002 21:31:30 -0000 1.30 --- EditorWindow.py 16 Sep 2002 02:13:15 -0000 1.31 *************** *** 20,23 **** --- 20,37 ---- TK_TABWIDTH_DEFAULT = 8 + def _find_module(fullname, path=None): + """Version of imp.find_module() that handles hierarchical module names""" + + file = None + for tgt in fullname.split('.'): + if file is not None: + file.close() # close intermediate files + (file, filename, descr) = imp.find_module(tgt, path) + if descr[2] == imp.PY_SOURCE: + break # find but not load the source file + module = imp.load_module(tgt, file, filename, descr) + path = module.__path__ + return file, filename, descr + class EditorWindow: from Percolator import Percolator *************** *** 184,188 **** def set_line_and_column(self, event=None): ! line, column = string.split(self.text.index(INSERT), '.') self.status_bar.set_label('column', 'Col: %s' % column) self.status_bar.set_label('line', 'Ln: %s' % line) --- 198,202 ---- def set_line_and_column(self, event=None): ! line, column = self.text.index(INSERT).split('.') self.status_bar.set_label('column', 'Col: %s' % column) self.status_bar.set_label('line', 'Ln: %s' % line) *************** *** 347,351 **** name = "" else: ! name = string.strip(name) if not name: name = tkSimpleDialog.askstring("Module", --- 361,365 ---- name = "" else: ! name = name.strip() if not name: name = tkSimpleDialog.askstring("Module", *************** *** 354,364 **** parent=self.text) if name: ! name = string.strip(name) if not name: return - # XXX Ought to support package syntax # XXX Ought to insert current file's directory in front of path try: ! (f, file, (suffix, mode, type)) = imp.find_module(name) except (NameError, ImportError), msg: tkMessageBox.showerror("Import error", str(msg), parent=self.text) --- 368,377 ---- parent=self.text) if name: ! name = name.strip() if not name: return # XXX Ought to insert current file's directory in front of path try: ! (f, file, (suffix, mode, type)) = _find_module(name) except (NameError, ImportError), msg: tkMessageBox.showerror("Import error", str(msg), parent=self.text) *************** *** 402,409 **** def ispythonsource(self, filename): if not filename: ! return 1 base, ext = os.path.splitext(os.path.basename(filename)) if os.path.normcase(ext) in (".py", ".pyw"): ! return 1 try: f = open(filename) --- 415,422 ---- def ispythonsource(self, filename): if not filename: ! return True base, ext = os.path.splitext(os.path.basename(filename)) if os.path.normcase(ext) in (".py", ".pyw"): ! return True try: f = open(filename) *************** *** 411,416 **** f.close() except IOError: ! return 0 ! return line[:2] == '#!' and string.find(line, 'python') >= 0 def close_hook(self): --- 424,429 ---- f.close() except IOError: ! return False ! return line.startswith('#!') and 'python' in line def close_hook(self): *************** *** 622,626 **** lineno = self.getlineno(mark) height = bot - top ! newtop = max(1, lineno - height/2) text.yview(float(newtop)) --- 635,639 ---- lineno = self.getlineno(mark) height = bot - top ! newtop = max(1, lineno - height//2) text.yview(float(newtop)) *************** *** 713,717 **** self.apply_bindings(keydefs) for vevent in keydefs.keys(): ! methodname = string.replace(vevent, "-", "_") while methodname[:1] == '<': methodname = methodname[1:] --- 726,730 ---- self.apply_bindings(keydefs) for vevent in keydefs.keys(): ! methodname = vevent.replace("-", "_") while methodname[:1] == '<': methodname = methodname[1:] *************** *** 1301,1305 **** # Helper to extract the underscore from a string, e.g. # prepstr("Co_py") returns (2, "Copy"). ! i = string.find(s, '_') if i >= 0: s = s[:i] + s[i+1:] --- 1314,1318 ---- # Helper to extract the underscore from a string, e.g. # prepstr("Co_py") returns (2, "Copy"). ! i = s.find('_') if i >= 0: s = s[:i] + s[i+1:] *************** *** 1318,1322 **** return "" s = keylist[0] ! s = re.sub(r"-[a-z]\b", lambda m: string.upper(m.group()), s) s = re.sub(r"\b\w+\b", lambda m: keynames.get(m.group(), m.group()), s) s = re.sub("Key-", "", s) --- 1331,1335 ---- return "" s = keylist[0] ! s = re.sub(r"-[a-z]\b", lambda m: m.group().upper(), s) s = re.sub(r"\b\w+\b", lambda m: keynames.get(m.group(), m.group()), s) s = re.sub("Key-", "", s) From kbk@users.sourceforge.net Mon Sep 16 03:22:22 2002 From: kbk@users.sourceforge.net (Kurt B. Kaiser) Date: Sun, 15 Sep 2002 19:22:22 -0700 Subject: [Idle-dev] CVS: idle FormatParagraph.py,1.4,1.5 Message-ID: Update of /cvsroot/idlefork/idle In directory usw-pr-cvs1:/tmp/cvs-serv28330 Modified Files: FormatParagraph.py Log Message: Merge Py Idle changes: Rev 1.10 (string methods) Index: FormatParagraph.py =================================================================== RCS file: /cvsroot/idlefork/idle/FormatParagraph.py,v retrieving revision 1.4 retrieving revision 1.5 diff -C2 -r1.4 -r1.5 *** FormatParagraph.py 19 Jan 2002 10:41:51 -0000 1.4 --- FormatParagraph.py 16 Sep 2002 02:22:19 -0000 1.5 *************** *** 15,19 **** # * Fancy comments, like this bulleted list, arent handled :-) - import string import re --- 15,18 ---- *************** *** 43,54 **** if comment_header: # Reformat the comment lines - convert to text sans header. ! lines = string.split(data, "\n") lines = map(lambda st, l=len(comment_header): st[l:], lines) ! data = string.join(lines, "\n") # Reformat to 70 chars or a 20 char width, whichever is greater. format_width = max(70-len(comment_header), 20) newdata = reformat_paragraph(data, format_width) # re-split and re-insert the comment header. ! newdata = string.split(newdata, "\n") # If the block ends in a \n, we dont want the comment # prefix inserted after it. (Im not sure it makes sense to --- 42,53 ---- if comment_header: # Reformat the comment lines - convert to text sans header. ! lines = data.split("\n") lines = map(lambda st, l=len(comment_header): st[l:], lines) ! data = "\n".join(lines) # Reformat to 70 chars or a 20 char width, whichever is greater. format_width = max(70-len(comment_header), 20) newdata = reformat_paragraph(data, format_width) # re-split and re-insert the comment header. ! newdata = newdata.split("\n") # If the block ends in a \n, we dont want the comment # prefix inserted after it. (Im not sure it makes sense to *************** *** 61,65 **** newdata = newdata[:-1] builder = lambda item, prefix=comment_header: prefix+item ! newdata = string.join(map(builder, newdata), '\n') + block_suffix else: # Just a normal text format --- 60,64 ---- newdata = newdata[:-1] builder = lambda item, prefix=comment_header: prefix+item ! newdata = '\n'.join(map(builder, newdata)) + block_suffix else: # Just a normal text format *************** *** 77,81 **** def find_paragraph(text, mark): ! lineno, col = map(int, string.split(mark, ".")) line = text.get("%d.0" % lineno, "%d.0 lineend" % lineno) while text.compare("%d.0" % lineno, "<", "end") and is_all_white(line): --- 76,80 ---- def find_paragraph(text, mark): ! lineno, col = map(int, mark.split(".")) line = text.get("%d.0" % lineno, "%d.0 lineend" % lineno) while text.compare("%d.0" % lineno, "<", "end") and is_all_white(line): *************** *** 102,106 **** def reformat_paragraph(data, limit=70): ! lines = string.split(data, "\n") i = 0 n = len(lines) --- 101,105 ---- def reformat_paragraph(data, limit=70): ! lines = data.split("\n") i = 0 n = len(lines) *************** *** 123,129 **** if not word: continue # Can happen when line ends in whitespace ! if len(string.expandtabs(partial + word)) > limit and \ partial != indent1: ! new.append(string.rstrip(partial)) partial = indent2 partial = partial + word + " " --- 122,128 ---- if not word: continue # Can happen when line ends in whitespace ! if len((partial + word).expandtabs()) > limit and \ partial != indent1: ! new.append(partial.rstrip()) partial = indent2 partial = partial + word + " " *************** *** 131,138 **** partial = partial + " " i = i+1 ! new.append(string.rstrip(partial)) # XXX Should reformat remaining paragraphs as well new.extend(lines[i:]) ! return string.join(new, "\n") def is_all_white(line): --- 130,137 ---- partial = partial + " " i = i+1 ! new.append(partial.rstrip()) # XXX Should reformat remaining paragraphs as well new.extend(lines[i:]) ! return "\n".join(new) def is_all_white(line): From kbk@users.sourceforge.net Mon Sep 16 03:25:28 2002 From: kbk@users.sourceforge.net (Kurt B. Kaiser) Date: Sun, 15 Sep 2002 19:25:28 -0700 Subject: [Idle-dev] CVS: idle GrepDialog.py,1.2,1.3 Message-ID: Update of /cvsroot/idlefork/idle In directory usw-pr-cvs1:/tmp/cvs-serv29007 Modified Files: GrepDialog.py Log Message: Merge Py Idle changes: Rev 1.4 (string methods) Rev 1.5 Remove unnecessary imports Index: GrepDialog.py =================================================================== RCS file: /cvsroot/idlefork/idle/GrepDialog.py,v retrieving revision 1.2 retrieving revision 1.3 diff -C2 -r1.2 -r1.3 *** GrepDialog.py 4 Jul 2001 03:15:10 -0000 1.2 --- GrepDialog.py 16 Sep 2002 02:25:26 -0000 1.3 *************** *** 1,9 **** - import string import os - import re import fnmatch import sys from Tkinter import * - import tkMessageBox import SearchEngine from SearchDialogBase import SearchDialogBase --- 1,6 ---- From kbk@shore.net Mon Sep 16 22:11:05 2002 From: kbk@shore.net (Kurt B. Kaiser) Date: 16 Sep 2002 17:11:05 -0400 Subject: [Idle-dev] tempfile.py Message-ID: Do we want to track Rev 1.9 (tempfile interface) to Python Idle IOBinding.py at this time? The introduction of the new tempfile.py interface requires Python later than 9Aug or File/Print will error out. That's the only use of tempfile.py in Idlefork. KBK From guido@python.org Mon Sep 16 22:46:47 2002 From: guido@python.org (Guido van Rossum) Date: Mon, 16 Sep 2002 17:46:47 -0400 Subject: [Idle-dev] tempfile.py In-Reply-To: Your message of "Mon, 16 Sep 2002 17:11:05 EDT." References: Message-ID: <200209162146.g8GLklY28630@pcp02138704pcs.reston01.va.comcast.net> > Do we want to track Rev 1.9 (tempfile interface) to Python Idle > IOBinding.py at this time? > > The introduction of the new tempfile.py interface requires Python > later than 9Aug or File/Print will error out. > > That's the only use of tempfile.py in Idlefork. Better not track that one. It's better if Idlefork runs with Python 2.2(.1) -- I assume it still does, right? If with 2.3 it causes a warning on its use of mktemp, you might add a filterwarnings() call to suppress that. --Guido van Rossum (home page: http://www.python.org/~guido/) From kbk@users.sourceforge.net Mon Sep 16 23:03:40 2002 From: kbk@users.sourceforge.net (Kurt B. Kaiser) Date: Mon, 16 Sep 2002 15:03:40 -0700 Subject: [Idle-dev] CVS: idle IOBinding.py,1.7,1.8 Message-ID: Update of /cvsroot/idlefork/idle In directory usw-pr-cvs1:/tmp/cvs-serv19218 Modified Files: IOBinding.py Log Message: Merge Py Idle changes: Rev 1.5 tim_one Convert a pile of obvious "yes/no" functions to return bool. Rev 1.6 gvanrossum (partially merged previously, move line outside try: block) Provisional fix for writefile() [SF bug # 541730]. The problem was that an exception can occur in the text.get() call or in the write() call, when the text buffer contains non-ASCII characters. This causes the previous contents of the file to be lost. The provisional fix is to call str(self.text.get(...)) *before* opening the file, so that if the exception occurs, we never open the file. Two orthogonal better solutions have to wait for policy decisions: 1. We could try to encode the data as Latin-1 or as UTF-8; but that would require IDLE to grow a notion of file encoding which requires more thought. 2. We could make backups before overwriting a file. This requires more thought because it needs to be fast and cross-platform and configurable. Rev 1.7 gvanrossum (previously merged with modifications by Stephen M. Gava) Add primitive printing support for Unix and Windows. Rev 1.8 loewis Patch #590913: PEP 263 support. Rev 1.9 gvanrossum (tempfile.py interface -- deferred) Rev 1.10 tim_one whitespace normalization Rev 1.11 nnorwitz (deferred pending 1.9 integration) Index: IOBinding.py =================================================================== RCS file: /cvsroot/idlefork/idle/IOBinding.py,v retrieving revision 1.7 retrieving revision 1.8 diff -C2 -r1.7 -r1.8 *** IOBinding.py 21 Jul 2002 01:24:28 -0000 1.7 --- IOBinding.py 16 Sep 2002 22:03:37 -0000 1.8 *************** *** 7,10 **** --- 7,13 ---- import os + import types + import sys + import codecs import tempfile import tkFileDialog *************** *** 33,36 **** --- 36,104 ---- #$ unix + try: + from codecs import BOM_UTF8 + except ImportError: + # only available since Python 2.3 + BOM_UTF8 = '\xef\xbb\xbf' + + # Try setting the locale, so that we can find out + # what encoding to use + try: + import locale + locale.setlocale(locale.LC_CTYPE, "") + except ImportError: + pass + + encoding = "ascii" + if sys.platform == 'win32': + # On Windows, we could use "mbcs". However, to give the user + # a portable encoding name, we need to find the code page + try: + encoding = locale.getdefaultlocale()[1] + codecs.lookup(encoding) + except LookupError: + pass + else: + try: + # Different things can fail here: the locale module may not be + # loaded, it may not offer nl_langinfo, or CODESET, or the + # resulting codeset may be unknown to Python. We ignore all + # these problems, falling back to ASCII + encoding = locale.nl_langinfo(locale.CODESET) + codecs.lookup(encoding) + except (NameError, AttributeError, LookupError): + # Try getdefaultlocale well: it parses environment variables, + # which may give a clue. Unfortunately, getdefaultlocale has + # bugs that can cause ValueError. + try: + encoding = locale.getdefaultlocale()[1] + codecs.lookup(encoding) + except (ValueError, LookupError): + pass + + encoding = encoding.lower() + + coding_re = re.compile("coding[:=]\s*([-\w_.]+)") + def coding_spec(str): + + """Return the encoding declaration according to PEP 263. + Raise LookupError if the encoding is declared but unknown.""" + + # Only consider the first two lines + str = str.split("\n")[:2] + str = "\n".join(str) + + match = coding_re.search(str) + if not match: + return None + name = match.group(1) + # Check whether the encoding is known + import codecs + try: + codecs.lookup(name) + except LookupError: + # The standard encoding error does not indicate the encoding + raise LookupError, "Unknown encoding "+name + return name class IOBinding: *************** *** 45,48 **** --- 113,117 ---- self.__id_savecopy = self.text.bind("<>", self.save_a_copy) + self.fileencoding = None self.__id_print = self.text.bind("<>", self.print_window) *************** *** 130,135 **** except IOError, msg: tkMessageBox.showerror("I/O Error", str(msg), master=self.text) ! return 0 # We now convert all end-of-lines to '\n's eol = r"(\r\n)|\n|\r" # \r\n (Windows), \n (UNIX), or \r (Mac) --- 199,205 ---- except IOError, msg: tkMessageBox.showerror("I/O Error", str(msg), master=self.text) ! return False + chars = self.decode(chars) # We now convert all end-of-lines to '\n's eol = r"(\r\n)|\n|\r" # \r\n (Windows), \n (UNIX), or \r (Mac) *************** *** 143,147 **** self.text.mark_set("insert", "1.0") self.text.see("insert") ! return 1 def maybesave(self): --- 213,265 ---- self.text.mark_set("insert", "1.0") self.text.see("insert") ! return True ! ! def decode(self, chars): ! # Try to create a Unicode string. If that fails, let Tcl try ! # its best ! ! # Check presence of a UTF-8 signature first ! if chars.startswith(BOM_UTF8): ! try: ! chars = chars[3:].decode("utf-8") ! except UnicodeError: ! # has UTF-8 signature, but fails to decode... ! return chars ! else: ! # Indicates that this file originally had a BOM ! self.fileencoding = BOM_UTF8 ! return chars ! ! # Next look for coding specification ! try: ! enc = coding_spec(chars) ! except LookupError, name: ! tkMessageBox.showerror( ! title="Error loading the file", ! message="The encoding '%s' is not known to this Python "\ ! "installation. The file may not display correctly" % name, ! master = self.text) ! enc = None ! ! if enc: ! try: ! return unicode(chars, enc) ! except UnicodeError: ! pass ! ! # If it is ASCII, we need not to record anything ! try: ! return unicode(chars, 'ascii') ! except UnicodeError: ! pass ! ! # Finally, try the locale's encoding. This is deprecated; ! # the user should declare a non-ASCII encoding ! try: ! chars = unicode(chars, encoding) ! self.fileencoding = encoding ! except UnicodeError: ! pass ! return chars def maybesave(self): *************** *** 191,206 **** def writefile(self, filename): self.fixlastline() try: f = open(filename, "w") - chars = str(self.text.get("1.0", "end-1c")) f.write(chars) f.close() ## print "saved to", `filename` ! return 1 except IOError, msg: tkMessageBox.showerror("I/O Error", str(msg), master=self.text) ! return 0 def print_window(self, event): tempfilename = None --- 309,392 ---- def writefile(self, filename): self.fixlastline() + chars = self.encode(self.text.get("1.0", "end-1c")) try: f = open(filename, "w") f.write(chars) f.close() ## print "saved to", `filename` ! return True except IOError, msg: tkMessageBox.showerror("I/O Error", str(msg), master=self.text) ! return False ! ! def encode(self, chars): ! if isinstance(chars, types.StringType): ! # This is either plain ASCII, or Tk was returning mixed-encoding ! # text to us. Don't try to guess further. ! return chars ! ! # See whether there is anything non-ASCII in it. ! # If not, no need to figure out the encoding. ! try: ! return chars.encode('ascii') ! except UnicodeError: ! pass ! ! # If there is an encoding declared, try this first. ! try: ! enc = coding_spec(chars) ! failed = None ! except LookupError, msg: ! failed = msg ! enc = None ! if enc: ! try: ! return chars.encode(enc) ! except UnicodeError: ! failed = "Invalid encoding '%s'" % enc ! ! if failed: ! tkMessageBox.showerror( ! "I/O Error", ! "%s. Saving as UTF-8" % failed, ! master = self.text) ! ! # If there was a UTF-8 signature, use that. This should not fail ! if self.fileencoding == BOM_UTF8 or failed: ! return BOM_UTF8 + chars.encode("utf-8") ! ! # Try the original file encoding next, if any ! if self.fileencoding: ! try: ! return chars.encode(self.fileencoding) ! except UnicodeError: ! tkMessageBox.showerror( ! "I/O Error", ! "Cannot save this as '%s' anymore. Saving as UTF-8" \ ! % self.fileencoding, ! master = self.text) ! return BOM_UTF8 + chars.encode("utf-8") ! ! # Nothing was declared, and we had not determined an encoding ! # on loading. Recommend an encoding line. ! try: ! chars = chars.encode(encoding) ! enc = encoding ! except UnicodeError: ! chars = BOM_UTF8 + chars.encode("utf-8") ! enc = "utf-8" ! tkMessageBox.showerror( ! "I/O Error", ! "Non-ASCII found, yet no encoding declared. Add a line like\n" ! "# -*- coding: %s -*- \nto your file" % enc, ! master = self.text) ! return chars + def fixlastline(self): + c = self.text.get("end-2c") + if c != '\n': + self.text.insert("end-1c", "\n") + def print_window(self, event): tempfilename = None *************** *** 215,219 **** printPlatform=1 if platform == 'posix': #posix platform ! command = idleConf.GetOption('main','General','print-command-posix') command = command + " 2>&1" elif platform == 'nt': #win32 platform --- 401,406 ---- printPlatform=1 if platform == 'posix': #posix platform ! command = idleConf.GetOption('main','General', ! 'print-command-posix') command = command + " 2>&1" elif platform == 'nt': #win32 platform *************** *** 227,231 **** status = pipe.close() if status: ! output = "Printing failed (exit status 0x%x)\n" % status + output if output: output = "Printing command: %s\n" % repr(command) + output --- 414,419 ---- status = pipe.close() if status: ! output = "Printing failed (exit status 0x%x)\n" % \ ! status + output if output: output = "Printing command: %s\n" % repr(command) + output *************** *** 236,244 **** return "break" - def fixlastline(self): - c = self.text.get("end-2c") - if c != '\n': - self.text.insert("end-1c", "\n") - opendialog = None savedialog = None --- 424,427 ---- From kbk@users.sourceforge.net Mon Sep 16 23:09:21 2002 From: kbk@users.sourceforge.net (Kurt B. Kaiser) Date: Mon, 16 Sep 2002 15:09:21 -0700 Subject: [Idle-dev] CVS: idle IdleHistory.py,1.3,1.4 Message-ID: Update of /cvsroot/idlefork/idle In directory usw-pr-cvs1:/tmp/cvs-serv25379 Modified Files: IdleHistory.py Log Message: Merge Py Idle changes: Rev 1.5 doerwalter string methods Index: IdleHistory.py =================================================================== RCS file: /cvsroot/idlefork/idle/IdleHistory.py,v retrieving revision 1.3 retrieving revision 1.4 diff -C2 -r1.3 -r1.4 *** IdleHistory.py 13 Jul 2001 17:40:17 -0000 1.3 --- IdleHistory.py 16 Sep 2002 22:09:19 -0000 1.4 *************** *** 1,4 **** - import string - class History: --- 1,2 ---- *************** *** 23,31 **** # Get source code from start index to end index. Lines in the # text control may be separated by sys.ps2 . ! lines = string.split(self.text.get(start, end), self.output_sep) ! return string.join(lines, "\n") def _put_source(self, where, source): ! output = string.join(string.split(source, "\n"), self.output_sep) self.text.insert(where, output) --- 21,29 ---- # Get source code from start index to end index. Lines in the # text control may be separated by sys.ps2 . ! lines = self.text.get(start, end).split(self.output_sep) ! return "\n".join(lines) def _put_source(self, where, source): ! output = self.output_sep.join(source.split("\n")) self.text.insert(where, output) *************** *** 69,73 **** def history_store(self, source): ! source = string.strip(source) if len(source) > 2: # avoid duplicates --- 67,71 ---- def history_store(self, source): ! source = source.strip() if len(source) > 2: # avoid duplicates *************** *** 81,85 **** def recall(self, s): ! s = string.strip(s) self.text.tag_remove("sel", "1.0", "end") self.text.delete("iomark", "end-1c") --- 79,83 ---- def recall(self, s): ! s = s.strip() self.text.tag_remove("sel", "1.0", "end") self.text.delete("iomark", "end-1c") From kbk@users.sourceforge.net Mon Sep 16 23:16:08 2002 From: kbk@users.sourceforge.net (Kurt B. Kaiser) Date: Mon, 16 Sep 2002 15:16:08 -0700 Subject: [Idle-dev] CVS: idle ObjectBrowser.py,1.3,1.4 Message-ID: Update of /cvsroot/idlefork/idle In directory usw-pr-cvs1:/tmp/cvs-serv27517 Modified Files: ObjectBrowser.py Log Message: Merge Py Idle changes: Rev 1.4 tim_one Convert a pile of obvious "yes/no" functions to return bool Index: ObjectBrowser.py =================================================================== RCS file: /cvsroot/idlefork/idle/ObjectBrowser.py,v retrieving revision 1.3 retrieving revision 1.4 diff -C2 -r1.3 -r1.4 *** ObjectBrowser.py 13 Jul 2001 17:57:37 -0000 1.3 --- ObjectBrowser.py 16 Sep 2002 22:16:05 -0000 1.4 *************** *** 60,64 **** class InstanceTreeItem(ObjectTreeItem): def IsExpandable(self): ! return 1 def GetSubList(self): sublist = ObjectTreeItem.GetSubList(self) --- 60,64 ---- class InstanceTreeItem(ObjectTreeItem): def IsExpandable(self): ! return True def GetSubList(self): sublist = ObjectTreeItem.GetSubList(self) *************** *** 69,73 **** class ClassTreeItem(ObjectTreeItem): def IsExpandable(self): ! return 1 def GetSubList(self): sublist = ObjectTreeItem.GetSubList(self) --- 69,73 ---- class ClassTreeItem(ObjectTreeItem): def IsExpandable(self): ! return True def GetSubList(self): sublist = ObjectTreeItem.GetSubList(self) From mats@laplaza.org Tue Sep 17 03:44:25 2002 From: mats@laplaza.org (Mats Wichmann) Date: Mon, 16 Sep 2002 20:44:25 -0600 Subject: [Idle-dev] CVS: idle EditorWindow.py,1.30,1.31 In-Reply-To: Message-ID: <5.1.0.14.1.20020916204307.01ef4260@204.151.72.2> At 07:13 PM 9/15/2002 -0700, Kurt B. Kaiser wrote: >Update of /cvsroot/idlefork/idle >In directory usw-pr-cvs1:/tmp/cvs-serv22220 > >Modified Files: > EditorWindow.py >Log Message: >Merge Py Idle changes: > >Rev 1.39 GvR >Properly fix SF bug #507298 (Gregor Lingl): shellpython2.2 -Qnew smart >indent error > >Use // where int division is intended. (This breaks IDLE for use with >previous Python versions -- I don't care.) Is this kind of breakage really necessary? From guido@python.org Tue Sep 17 04:10:21 2002 From: guido@python.org (Guido van Rossum) Date: Mon, 16 Sep 2002 23:10:21 -0400 Subject: [Idle-dev] CVS: idle EditorWindow.py,1.30,1.31 In-Reply-To: Your message of "Mon, 16 Sep 2002 20:44:25 MDT." <5.1.0.14.1.20020916204307.01ef4260@204.151.72.2> References: <5.1.0.14.1.20020916204307.01ef4260@204.151.72.2> Message-ID: <200209170310.g8H3ALL00313@pcp02138704pcs.reston01.va.comcast.net> > At 07:13 PM 9/15/2002 -0700, Kurt B. Kaiser wrote: > >Update of /cvsroot/idlefork/idle > >In directory usw-pr-cvs1:/tmp/cvs-serv22220 > > > >Modified Files: > > EditorWindow.py > >Log Message: > >Merge Py Idle changes: > > > >Rev 1.39 GvR > >Properly fix SF bug #507298 (Gregor Lingl): shellpython2.2 -Qnew smart > >indent error > > > >Use // where int division is intended. (This breaks IDLE for use with > >previous Python versions -- I don't care.) Mats Wichmann: > Is this kind of breakage really necessary? It's pretty much a necessity to use Python 2.2 for the new code base anyway. Keeping it backwards compatible with 2.1 would be a pain, and given the small number of volunteer developers we've got, would discourage development. If it's really necessary to have a version of Idlefork running on Python 2.1, perhaps a separate volunteer force can work on a backport. (But I warn you, it's more than changing // back to /.) --Guido van Rossum (home page: http://www.python.org/~guido/) From noreply@sourceforge.net Tue Sep 17 04:23:20 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Mon, 16 Sep 2002 20:23:20 -0700 Subject: [Idle-dev] [ idlefork-Patches-610329 ] tempfile.py Interface Message-ID: Patches item #610329, was opened at 2002-09-16 22:23 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=309579&aid=610329&group_id=9579 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Kurt B. Kaiser (kbk) Assigned to: Kurt B. Kaiser (kbk) Summary: tempfile.py Interface Initial Comment: Attached patch must be integrated into IOBinding.py to track Python 2.3 Idle. Since Idlefork is intended to run under Python 2.2 it will not be merged at this time. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=309579&aid=610329&group_id=9579 From kbk@users.sourceforge.net Tue Sep 17 04:40:49 2002 From: kbk@users.sourceforge.net (Kurt B. Kaiser) Date: Mon, 16 Sep 2002 20:40:49 -0700 Subject: [Idle-dev] CVS: idle OutputWindow.py,1.5,1.6 Message-ID: Update of /cvsroot/idlefork/idle In directory usw-pr-cvs1:/tmp/cvs-serv13642 Modified Files: OutputWindow.py Log Message: Merge Py Idle changes: Rev 1.7 loewis Convert characters from the locale's encoding on output. Reject characters outside the locale's encoding on input. Index: OutputWindow.py =================================================================== RCS file: /cvsroot/idlefork/idle/OutputWindow.py,v retrieving revision 1.5 retrieving revision 1.6 diff -C2 -r1.5 -r1.6 *** OutputWindow.py 2 Sep 2002 21:29:40 -0000 1.5 --- OutputWindow.py 17 Sep 2002 03:40:47 -0000 1.6 *************** *** 3,6 **** --- 3,7 ---- import re import tkMessageBox + import IOBinding class OutputWindow(EditorWindow): *************** *** 35,38 **** --- 36,47 ---- def write(self, s, tags=(), mark="insert"): + # Tk assumes that byte strings are Latin-1; + # we assume that they are in the locale's encoding + if isinstance(s, str): + try: + s = unicode(s, IOBinding.encoding) + except UnicodeError: + # some other encoding; let Tcl deal with it + pass self.text.insert(mark, s, tags) self.text.see(mark) From kbk@users.sourceforge.net Tue Sep 17 04:43:40 2002 From: kbk@users.sourceforge.net (Kurt B. Kaiser) Date: Mon, 16 Sep 2002 20:43:40 -0700 Subject: [Idle-dev] CVS: idle ParenMatch.py,1.5,1.6 Message-ID: Update of /cvsroot/idlefork/idle In directory usw-pr-cvs1:/tmp/cvs-serv14236 Modified Files: ParenMatch.py Log Message: Merge Py Idle changes: Rev 1.6 doerwalter (string methods) Index: ParenMatch.py =================================================================== RCS file: /cvsroot/idlefork/idle/ParenMatch.py,v retrieving revision 1.5 retrieving revision 1.6 diff -C2 -r1.5 -r1.6 *** ParenMatch.py 14 Sep 2002 02:46:19 -0000 1.5 --- ParenMatch.py 17 Sep 2002 03:43:38 -0000 1.6 *************** *** 11,16 **** """ - import string - import PyParse from AutoIndent import AutoIndent, index2line --- 11,14 ---- *************** *** 167,174 **** or keysym_type(buf[i]) != right_keysym_type: return None ! lines_back = string.count(buf[i:], "\n") - 1 # subtract one for the "\n" added to please the parser upto_open = buf[:i] ! j = string.rfind(upto_open, "\n") + 1 # offset of column 0 of line offset = i - j return "%d.%d" % (lno - lines_back, offset) --- 165,172 ---- or keysym_type(buf[i]) != right_keysym_type: return None ! lines_back = buf[i:].count("\n") - 1 # subtract one for the "\n" added to please the parser upto_open = buf[:i] ! j = upto_open.rfind("\n") + 1 # offset of column 0 of line offset = i - j return "%d.%d" % (lno - lines_back, offset) From kbk@users.sourceforge.net Tue Sep 17 04:55:15 2002 From: kbk@users.sourceforge.net (Kurt B. Kaiser) Date: Mon, 16 Sep 2002 20:55:15 -0700 Subject: [Idle-dev] CVS: idle PyParse.py,1.4,1.5 Message-ID: Update of /cvsroot/idlefork/idle In directory usw-pr-cvs1:/tmp/cvs-serv16222 Modified Files: PyParse.py Log Message: Merge Py Idle changes: Rev 1.10 doerwalter (string methods) Index: PyParse.py =================================================================== RCS file: /cvsroot/idlefork/idle/PyParse.py,v retrieving revision 1.4 retrieving revision 1.5 diff -C2 -r1.4 -r1.5 *** PyParse.py 14 Jul 2001 04:59:24 -0000 1.4 --- PyParse.py 17 Sep 2002 03:55:13 -0000 1.5 *************** *** 1,3 **** - import string import re import sys --- 1,2 ---- *************** *** 8,12 **** if 0: # for throwaway debugging output def dump(*stuff): ! sys.__stdout__.write(string.join(map(str, stuff), " ") + "\n") # Find what looks like the start of a popular stmt. --- 7,11 ---- if 0: # for throwaway debugging output def dump(*stuff): ! sys.__stdout__.write(" ".join(map(str, stuff)) + "\n") # Find what looks like the start of a popular stmt. *************** *** 104,108 **** for ch in "\"'\\\n#": _tran[ord(ch)] = ch ! _tran = string.join(_tran, '') del ch --- 103,107 ---- for ch in "\"'\\\n#": _tran[ord(ch)] = ch ! _tran = ''.join(_tran) del ch *************** *** 154,158 **** def find_good_parse_start(self, use_ps1, is_char_in_string=None, - _rfind=string.rfind, _synchre=_synchre): str, pos = self.str, None --- 153,156 ---- *************** *** 160,164 **** # shell window ps1 = '\n' + sys.ps1 ! i = _rfind(str, ps1) if i >= 0: pos = i + len(ps1) --- 158,162 ---- # shell window ps1 = '\n' + sys.ps1 ! i = str.rfind(ps1) if i >= 0: pos = i + len(ps1) *************** *** 179,186 **** limit = len(str) for tries in range(5): ! i = _rfind(str, ":\n", 0, limit) if i < 0: break ! i = _rfind(str, '\n', 0, i) + 1 # start of colon line m = _synchre(str, i, limit) if m and not is_char_in_string(m.start()): --- 177,184 ---- limit = len(str) for tries in range(5): ! i = str.rfind(":\n", 0, limit) if i < 0: break ! i = str.rfind('\n', 0, i) + 1 # start of colon line m = _synchre(str, i, limit) if m and not is_char_in_string(m.start()): *************** *** 227,231 **** # Creates self.{goodlines, continuation}. ! def _study1(self, _replace=string.replace, _find=string.find): if self.study_level >= 1: return --- 225,229 ---- # Creates self.{goodlines, continuation}. ! def _study1(self): if self.study_level >= 1: return *************** *** 237,246 **** # by a factor of 10-40, and so greatly speed the following loop. str = self.str ! str = string.translate(str, _tran) ! str = _replace(str, 'xxxxxxxx', 'x') ! str = _replace(str, 'xxxx', 'x') ! str = _replace(str, 'xx', 'x') ! str = _replace(str, 'xx', 'x') ! str = _replace(str, '\nx', '\n') # note that replacing x\n with \n would be incorrect, because # x may be preceded by a backslash --- 235,244 ---- # by a factor of 10-40, and so greatly speed the following loop. str = self.str ! str = str.translate(_tran) ! str = str.replace('xxxxxxxx', 'x') ! str = str.replace('xxxx', 'x') ! str = str.replace('xx', 'x') ! str = str.replace('xx', 'x') ! str = str.replace('\nx', '\n') # note that replacing x\n with \n would be incorrect, because # x may be preceded by a backslash *************** *** 323,327 **** if ch == '#': # consume the comment ! i = _find(str, '\n', i) assert i >= 0 continue --- 321,325 ---- if ch == '#': # consume the comment ! i = str.find('\n', i) assert i >= 0 continue *************** *** 364,369 **** # if continuation is C_BRACKET, index of last open bracket ! def _study2(self, _rfind=string.rfind, _find=string.find, ! _ws=string.whitespace): if self.study_level >= 2: return --- 362,366 ---- # if continuation is C_BRACKET, index of last open bracket ! def _study2(self): if self.study_level >= 2: return *************** *** 382,386 **** for nothing in range(goodlines[i-1], goodlines[i]): # tricky: sets p to 0 if no preceding newline ! p = _rfind(str, '\n', 0, p-1) + 1 # The stmt str[p:q] isn't a continuation, but may be blank # or a non-indenting comment line. --- 379,383 ---- for nothing in range(goodlines[i-1], goodlines[i]): # tricky: sets p to 0 if no preceding newline ! p = str.rfind('\n', 0, p-1) + 1 # The stmt str[p:q] isn't a continuation, but may be blank # or a non-indenting comment line. *************** *** 445,449 **** if ch == '#': # consume comment and trailing newline ! p = _find(str, '\n', p, q) + 1 assert p > 0 continue --- 442,446 ---- if ch == '#': # consume comment and trailing newline ! p = str.find('\n', p, q) + 1 assert p > 0 continue *************** *** 466,470 **** # of spaces the next line should be indented. ! def compute_bracket_indent(self, _find=string.find): self._study2() assert self.continuation == C_BRACKET --- 463,467 ---- # of spaces the next line should be indented. ! def compute_bracket_indent(self): self._study2() assert self.continuation == C_BRACKET *************** *** 472,476 **** str = self.str n = len(str) ! origi = i = string.rfind(str, '\n', 0, j) + 1 j = j+1 # one beyond open bracket # find first list item; set i to start of its line --- 469,473 ---- str = self.str n = len(str) ! origi = i = str.rfind('\n', 0, j) + 1 j = j+1 # one beyond open bracket # find first list item; set i to start of its line *************** *** 483,487 **** else: # this line is junk; advance to next line ! i = j = _find(str, '\n', j) + 1 else: # nothing interesting follows the bracket; --- 480,484 ---- else: # this line is junk; advance to next line ! i = j = str.find('\n', j) + 1 else: # nothing interesting follows the bracket; *************** *** 491,496 **** j = j+1 extra = self.indentwidth ! return len(string.expandtabs(str[i:j], ! self.tabwidth)) + extra # Return number of physical lines in last stmt (whether or not --- 488,492 ---- j = j+1 extra = self.indentwidth ! return len(str[i:j].expandtabs(self.tabwidth)) + extra # Return number of physical lines in last stmt (whether or not *************** *** 518,522 **** # See whether the initial line starts an assignment stmt; i.e., # look for an = operator ! endpos = string.find(str, '\n', startpos) + 1 found = level = 0 while i < endpos: --- 514,518 ---- # See whether the initial line starts an assignment stmt; i.e., # look for an = operator ! endpos = str.find('\n', startpos) + 1 found = level = 0 while i < endpos: *************** *** 554,559 **** i = i+1 ! return len(string.expandtabs(str[self.stmt_start : ! i], self.tabwidth)) + 1 --- 550,554 ---- i = i+1 ! return len(str[self.stmt_start:i].expandtabs(\ self.tabwidth)) + 1 From mats@laplaza.org Tue Sep 17 14:53:31 2002 From: mats@laplaza.org (Mats Wichmann) Date: Tue, 17 Sep 2002 07:53:31 -0600 Subject: [Idle-dev] CVS: idle EditorWindow.py,1.30,1.31 In-Reply-To: <200209170310.g8H3ALL00313@pcp02138704pcs.reston01.va.comca st.net> References: <5.1.0.14.1.20020916204307.01ef4260@204.151.72.2> Message-ID: <5.1.0.14.1.20020917074806.01fe8a08@204.151.72.2> >It's pretty much a necessity to use Python 2.2 for the new code base >anyway. Keeping it backwards compatible with 2.1 would be a pain, and >given the small number of volunteer developers we've got, would >discourage development. It's okay by me. I care if idle(fork) becomes 2.2-incompatible. I don't care much about 2.1. Just wanted to know that it had been thought through; since there's more than // involved the choice has been made anyway. From kbk@shore.net Tue Sep 17 15:21:57 2002 From: kbk@shore.net (Kurt B. Kaiser) Date: 17 Sep 2002 10:21:57 -0400 Subject: [Idle-dev] tempfile.py In-Reply-To: <200209162146.g8GLklY28630@pcp02138704pcs.reston01.va.comcast.net> References: <200209162146.g8GLklY28630@pcp02138704pcs.reston01.va.comcast.net> Message-ID: [GvR] > Better not track that one. It's better if Idlefork runs with Python > 2.2(.1) -- I assume it still does, right? > > If with 2.3 it causes a warning on its use of mktemp, you might add a > filterwarnings() call to suppress that. [Mats Wichman] > I care if idle(fork) becomes 2.2-incompatible. I don't care much > about 2.1. Just wanted to know that it had been thought through; > since there's more than // involved the choice has been made anyway. The intention is to support 2.2, but not 2.1. I don't think that Stephen and I have intentionally written anything which restricts Idlefork to 2.3. However, I do run 2.3a0. Maybe I should drop back to 2.2. to better test compliance. Regards, KBK From guido@python.org Tue Sep 17 15:50:10 2002 From: guido@python.org (Guido van Rossum) Date: Tue, 17 Sep 2002 10:50:10 -0400 Subject: [Idle-dev] tempfile.py In-Reply-To: Your message of "Tue, 17 Sep 2002 10:21:57 EDT." References: <200209162146.g8GLklY28630@pcp02138704pcs.reston01.va.comcast.net> Message-ID: <200209171450.g8HEoAb21653@odiug.zope.com> > I don't think that Stephen and I have intentionally written anything > which restricts Idlefork to 2.3. However, I do run 2.3a0. Maybe I > should drop back to 2.2. to better test compliance. +1. Added advantage: if after developing with 2.2 for a while, when yo umove to 2.3 you find anything that doesn't work, you can report it to the compatibility police. --Guido van Rossum (home page: http://www.python.org/~guido/) From noreply@sourceforge.net Tue Sep 17 21:08:38 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 17 Sep 2002 13:08:38 -0700 Subject: [Idle-dev] [ idlefork-Bugs-610756 ] Problem in StackViewer.get_stack() Message-ID: Bugs item #610756, was opened at 2002-09-17 16:08 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=610756&group_id=9579 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: Problem in StackViewer.get_stack() Initial Comment: See http://python.org/sf/608595 in StackViewer.py get_stack() (line 114) there is a reference to an invalid variable (self). This entire while loop is not executed. Should the while loop be removed? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=610756&group_id=9579 From noreply@sourceforge.net Tue Sep 17 21:16:19 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 17 Sep 2002 13:16:19 -0700 Subject: [Idle-dev] [ idlefork-Patches-610763 ] Extension to Calltips / Show attributes Message-ID: Patches item #610763, was opened at 2002-09-17 16:16 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=309579&aid=610763&group_id=9579 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: Extension to Calltips / Show attributes Initial Comment: See http://python.org/sf/525109 just don't want to lose track of it, if it's desirable in idlefork. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=309579&aid=610763&group_id=9579 From noreply@sourceforge.net Tue Sep 17 22:22:56 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 17 Sep 2002 14:22:56 -0700 Subject: [Idle-dev] [ idlefork-Bugs-610756 ] Problem in StackViewer.get_stack() Message-ID: Bugs item #610756, was opened at 2002-09-17 15:08 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=610756&group_id=9579 Category: None Group: None Status: Open >Resolution: Accepted Priority: 5 Submitted By: Neal Norwitz (nnorwitz) >Assigned to: Kurt B. Kaiser (kbk) Summary: Problem in StackViewer.get_stack() Initial Comment: See http://python.org/sf/608595 in StackViewer.py get_stack() (line 114) there is a reference to an invalid variable (self). This entire while loop is not executed. Should the while loop be removed? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=610756&group_id=9579 From noreply@sourceforge.net Tue Sep 17 22:24:18 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Tue, 17 Sep 2002 14:24:18 -0700 Subject: [Idle-dev] [ idlefork-Bugs-610756 ] Problem in StackViewer.get_stack() Message-ID: Bugs item #610756, was opened at 2002-09-17 15:08 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=610756&group_id=9579 Category: None Group: None Status: Open Resolution: Accepted Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Kurt B. Kaiser (kbk) Summary: Problem in StackViewer.get_stack() Initial Comment: See http://python.org/sf/608595 in StackViewer.py get_stack() (line 114) there is a reference to an invalid variable (self). This entire while loop is not executed. Should the while loop be removed? ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2002-09-17 16:24 Message: Logged In: YES user_id=149084 Defer until merge is completed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=610756&group_id=9579 From kbk@shore.net Wed Sep 18 00:47:34 2002 From: kbk@shore.net (Kurt B. Kaiser) Date: 17 Sep 2002 19:47:34 -0400 Subject: [Idle-dev] Python Idle Moratorium Message-ID: Guido has posted a moratorium on futher Python Idle development, with the intention that work be shifted to Idlefork. I'd like to extend an invitation to any interested developers with Python CVS access to join the Idlefork project to continue their idle ways ;) Send me an email and I'll set you up with Idlefork access. =============== copy from python-dev ============================= http://mail.python.org/pipermail/python-dev/2002-September/028776.html [GvR] I'd like to put a stop to all changes to the version of IDLE in the Python source tree (Tools/idle/* -- let's call it Python-idle). The current crop of changes are being merged into Idlefork, the separate SF project where a new IDLE version is being cooked. I hope that Idlefork will be ready to be merged back into Python before we release Python 2.3, and that will be easiest if we can simply abandon the existing Python-idle code and copy the latest Idlefork in its place. Any changes made to the Python-idle code will be lost at that point. If you have a bug, fix or feature for IDLE, please suggest it on the idle-dev mailing list or on Idlefork's SF bug/patch managers! ==================================================================== Note that Idlefork is 2.2 compliant; code requiring 2.3 should be deferred until the merge with Python: ================ copy from python-dev ============================== http://mail.python.org/pipermail/python-dev/2002-September/028782.html > Does Idlefork also require CVS Python? [GvR] Not yet, AFAIK, it requires 2.2. A very small number of changes to Python-idle could not be merged for that reason (e.g. mkstemp). I'd like to keep Idlefork working with 2.2 so there's a reasonable potential user base for an Idlefork release. =================================================================== KBK From kbk@users.sourceforge.net Wed Sep 18 03:30:01 2002 From: kbk@users.sourceforge.net (Kurt B. Kaiser) Date: Tue, 17 Sep 2002 19:30:01 -0700 Subject: [Idle-dev] CVS: idle PyShell.py,1.24,1.25 Message-ID: Update of /cvsroot/idlefork/idle In directory usw-pr-cvs1:/tmp/cvs-serv20002 Modified Files: PyShell.py Log Message: Merge Py Idle changes: Rev 1.35 fdrake Use string.ascii_letters instead of string.letters (SF bug #226706). Move computation of sets of characters out of the body of the function that uses them. Rev 1.36 tim_one Convert a pile of obvious "yes/no" functions to return bool Rev 1.37 (skip, done differently in Idlefork) Rev 1.38 loewis Patch #590913: PEP 263 support. Rev 1.39 loewis Convert characters from the locale's encoding on output. Reject characters outside the locale's encoding on input. Rev 1.40 doerwalter (string methods) Rev 1.41 (skipped, done by GvR in rpc) Index: PyShell.py =================================================================== RCS file: /cvsroot/idlefork/idle/PyShell.py,v retrieving revision 1.24 retrieving revision 1.25 diff -C2 -r1.24 -r1.25 *** PyShell.py 14 Sep 2002 02:50:56 -0000 1.24 --- PyShell.py 18 Sep 2002 02:29:59 -0000 1.25 *************** *** 290,293 **** --- 290,301 ---- self.save_warnings_filters = warnings.filters[:] warnings.filterwarnings(action="error", category=SyntaxWarning) + if isinstance(source, types.UnicodeType): + import IOBinding + try: + source = source.encode(IOBinding.encoding) + except UnicodeError: + self.tkconsole.resetoutput() + self.write("Unsupported characters in input") + return try: return InteractiveInterpreter.runsource(self, source, filename) *************** *** 301,308 **** filename = "" % self.gid self.gid = self.gid + 1 ! lines = string.split(source, "\n") linecache.cache[filename] = len(source)+1, 0, lines, filename return filename ! def showsyntaxerror(self, filename=None): """Extend base class method: Add Colorizing --- 309,318 ---- filename = "" % self.gid self.gid = self.gid + 1 ! lines = source.split("\n") linecache.cache[filename] = len(source)+1, 0, lines, filename return filename ! ! IDENTCHARS = string.ascii_letters + string.digits + "_" ! def showsyntaxerror(self, filename=None): """Extend base class method: Add Colorizing *************** *** 327,331 **** text.see(pos) char = text.get(pos) ! if char and char in string.letters + string.digits + "_": text.tag_add("ERROR", pos + " wordstart", pos) self.tkconsole.resetoutput() --- 337,341 ---- text.see(pos) char = text.get(pos) ! if char and char in IDENTCHARS: text.tag_add("ERROR", pos + " wordstart", pos) self.tkconsole.resetoutput() *************** *** 599,603 **** def ispythonsource(self, filename): "Override EditorWindow method: never remove the colorizer" ! return 1 def short_title(self): --- 609,613 ---- def ispythonsource(self, filename): "Override EditorWindow method: never remove the colorizer" ! return True def short_title(self): *************** *** 642,646 **** def isatty(self): ! return 1 def cancel_callback(self, event): --- 652,656 ---- def isatty(self): ! return True def cancel_callback(self, event): *************** *** 736,740 **** # beyond the cursor, erase that whitespace first s = self.text.get("insert", "end-1c") ! if s and not string.strip(s): self.text.delete("insert", "end-1c") # If we're in the current input before its last line, --- 746,750 ---- # beyond the cursor, erase that whitespace first s = self.text.get("insert", "end-1c") ! if s and not s.strip(): self.text.delete("insert", "end-1c") # If we're in the current input before its last line, *************** *** 853,857 **** def isatty(self): ! return 1 --- 863,867 ---- def isatty(self): ! return True From kbk@users.sourceforge.net Wed Sep 18 03:56:12 2002 From: kbk@users.sourceforge.net (Kurt B. Kaiser) Date: Tue, 17 Sep 2002 19:56:12 -0700 Subject: [Idle-dev] CVS: idle ReplaceDialog.py,1.4,1.5 Message-ID: Update of /cvsroot/idlefork/idle In directory usw-pr-cvs1:/tmp/cvs-serv25902 Modified Files: ReplaceDialog.py Log Message: Merge Py Idle changes: Rev 1.5 tim_one Convert a pile of obvious "yes/no" functions to return bool Rev 1.6 GvR Rev 1.7 Gvr (Already merged Idlefork ReplaceDialog.py 1.3.2.1 and 1.4) Rev 1.8 doerwalter (string methods) Rev 1.9 nnorwitz Remove unnecessary imports Index: ReplaceDialog.py =================================================================== RCS file: /cvsroot/idlefork/idle/ReplaceDialog.py,v retrieving revision 1.4 retrieving revision 1.5 diff -C2 -r1.4 -r1.5 *** ReplaceDialog.py 14 Sep 2002 02:53:05 -0000 1.4 --- ReplaceDialog.py 18 Sep 2002 02:56:10 -0000 1.5 *************** *** 1,8 **** - import string - import os - import re - import fnmatch from Tkinter import * - import tkMessageBox import SearchEngine from SearchDialogBase import SearchDialogBase --- 1,3 ---- *************** *** 112,121 **** def do_find(self, ok=0): if not self.engine.getprog(): ! return 0 text = self.text res = self.engine.search_text(text, None, ok) if not res: text.bell() ! return 0 line, m = res i, j = m.span() --- 107,116 ---- def do_find(self, ok=0): if not self.engine.getprog(): ! return False text = self.text res = self.engine.search_text(text, None, ok) if not res: text.bell() ! return False line, m = res i, j = m.span() *************** *** 124,133 **** self.show_hit(first, last) self.ok = 1 ! return 1 def do_replace(self): prog = self.engine.getprog() if not prog: ! return 0 text = self.text try: --- 119,128 ---- self.show_hit(first, last) self.ok = 1 ! return True def do_replace(self): prog = self.engine.getprog() if not prog: ! return False text = self.text try: *************** *** 142,146 **** m = prog.match(chars, col) if not prog: ! return 0 new = m.expand(self.replvar.get()) text.mark_set("insert", first) --- 137,141 ---- m = prog.match(chars, col) if not prog: ! return False new = m.expand(self.replvar.get()) text.mark_set("insert", first) *************** *** 153,157 **** self.show_hit(first, text.index("insert")) self.ok = 0 ! return 1 def show_hit(self, first, last): --- 148,152 ---- self.show_hit(first, text.index("insert")) self.ok = 0 ! return True def show_hit(self, first, last): From kbk@users.sourceforge.net Wed Sep 18 04:05:21 2002 From: kbk@users.sourceforge.net (Kurt B. Kaiser) Date: Tue, 17 Sep 2002 20:05:21 -0700 Subject: [Idle-dev] CVS: idle ScriptBinding.py,1.9,1.10 Message-ID: Update of /cvsroot/idlefork/idle In directory usw-pr-cvs1:/tmp/cvs-serv29108 Modified Files: ScriptBinding.py Log Message: Merge Py Idle changes: Rev 1.11 GvR Fix for SF bug #448835. Fix this to work with the new (still undocumented) tabnanny API. I'm afraid Stephen will have to add this fix to the IDLE fork code base as well. Rev 1.12 rhettinger (skip, done differently in Idlefork) Rev 1.13 time_one (skip, NA) Index: ScriptBinding.py =================================================================== RCS file: /cvsroot/idlefork/idle/ScriptBinding.py,v retrieving revision 1.9 retrieving revision 1.10 diff -C2 -r1.9 -r1.10 *** ScriptBinding.py 5 Sep 2002 02:31:20 -0000 1.9 --- ScriptBinding.py 18 Sep 2002 03:05:19 -0000 1.10 *************** *** 66,73 **** import tabnanny import tokenize - tabnanny.reset_globals() f = open(filename, 'r') try: ! tokenize.tokenize(f.readline, tabnanny.tokeneater) except tokenize.TokenError, msg: self.errorbox("Token error", --- 66,72 ---- import tabnanny import tokenize f = open(filename, 'r') try: ! tabnanny.process_tokens(tokenize.generate_tokens(f.readline)) except tokenize.TokenError, msg: self.errorbox("Token error", From kbk@users.sourceforge.net Wed Sep 18 04:10:12 2002 From: kbk@users.sourceforge.net (Kurt B. Kaiser) Date: Tue, 17 Sep 2002 20:10:12 -0700 Subject: [Idle-dev] CVS: idle SearchDialog.py,1.2,1.3 Message-ID: Update of /cvsroot/idlefork/idle In directory usw-pr-cvs1:/tmp/cvs-serv30384 Modified Files: SearchDialog.py Log Message: Merge Py Idle changes: Rev 1.3 tim_one Convert a pile of obvious "yes/no" functions to return bool. Index: SearchDialog.py =================================================================== RCS file: /cvsroot/idlefork/idle/SearchDialog.py,v retrieving revision 1.2 retrieving revision 1.3 diff -C2 -r1.2 -r1.3 *** SearchDialog.py 4 Jul 2001 03:15:10 -0000 1.2 --- SearchDialog.py 18 Sep 2002 03:10:10 -0000 1.3 *************** *** 35,41 **** if not self.engine.getpat(): self.open(text) ! return 0 if not self.engine.getprog(): ! return 0 res = self.engine.search_text(text) if res: --- 35,41 ---- if not self.engine.getpat(): self.open(text) ! return False if not self.engine.getprog(): ! return False res = self.engine.search_text(text) if res: *************** *** 49,53 **** if selfirst == first and sellast == last: text.bell() ! return 0 except TclError: pass --- 49,53 ---- if selfirst == first and sellast == last: text.bell() ! return False except TclError: pass *************** *** 56,63 **** text.mark_set("insert", self.engine.isback() and first or last) text.see("insert") ! return 1 else: text.bell() ! return 0 def find_selection(self, text): --- 56,63 ---- text.mark_set("insert", self.engine.isback() and first or last) text.see("insert") ! return True else: text.bell() ! return False def find_selection(self, text): From kbk@users.sourceforge.net Wed Sep 18 04:12:21 2002 From: kbk@users.sourceforge.net (Kurt B. Kaiser) Date: Tue, 17 Sep 2002 20:12:21 -0700 Subject: [Idle-dev] CVS: idle SearchDialogBase.py,1.2,1.3 Message-ID: Update of /cvsroot/idlefork/idle In directory usw-pr-cvs1:/tmp/cvs-serv30902 Modified Files: SearchDialogBase.py Log Message: Merge Py Idle changes: Rev 1.2 doerwalter (string methods) Index: SearchDialogBase.py =================================================================== RCS file: /cvsroot/idlefork/idle/SearchDialogBase.py,v retrieving revision 1.2 retrieving revision 1.3 diff -C2 -r1.2 -r1.3 *** SearchDialogBase.py 4 Jul 2001 03:15:10 -0000 1.2 --- SearchDialogBase.py 18 Sep 2002 03:12:18 -0000 1.3 *************** *** 1,3 **** - import string from Tkinter import * --- 1,2 ---- From kbk@users.sourceforge.net Wed Sep 18 04:14:13 2002 From: kbk@users.sourceforge.net (Kurt B. Kaiser) Date: Tue, 17 Sep 2002 20:14:13 -0700 Subject: [Idle-dev] CVS: idle SearchEngine.py,1.2,1.3 Message-ID: Update of /cvsroot/idlefork/idle In directory usw-pr-cvs1:/tmp/cvs-serv31457 Modified Files: SearchEngine.py Log Message: Merge PyIdle changes: Rev 1.3 doerwalter (string methods) Index: SearchEngine.py =================================================================== RCS file: /cvsroot/idlefork/idle/SearchEngine.py,v retrieving revision 1.2 retrieving revision 1.3 diff -C2 -r1.2 -r1.3 *** SearchEngine.py 4 Jul 2001 03:15:10 -0000 1.2 --- SearchEngine.py 18 Sep 2002 03:14:11 -0000 1.3 *************** *** 1,3 **** - import string import re from Tkinter import * --- 1,2 ---- *************** *** 176,180 **** wrap = 0 pos = text.index("end-1c") ! line, col = map(int, string.split(pos, ".")) chars = text.get("%d.0" % line, "%d.0" % (line+1)) col = len(chars) - 1 --- 175,179 ---- wrap = 0 pos = text.index("end-1c") ! line, col = map(int, pos.split(".")) chars = text.get("%d.0" % line, "%d.0" % (line+1)) col = len(chars) - 1 *************** *** 218,221 **** def get_line_col(index): ! line, col = map(int, string.split(index, ".")) # Fails on invalid index return line, col --- 217,220 ---- def get_line_col(index): ! line, col = map(int, index.split(".")) # Fails on invalid index return line, col From kbk@users.sourceforge.net Wed Sep 18 04:15:58 2002 From: kbk@users.sourceforge.net (Kurt B. Kaiser) Date: Tue, 17 Sep 2002 20:15:58 -0700 Subject: [Idle-dev] CVS: idle StackViewer.py,1.5,1.6 Message-ID: Update of /cvsroot/idlefork/idle In directory usw-pr-cvs1:/tmp/cvs-serv31808 Modified Files: StackViewer.py Log Message: Merge Py Idle changes: Rev 1.17 doerwalter (string methods) Index: StackViewer.py =================================================================== RCS file: /cvsroot/idlefork/idle/StackViewer.py,v retrieving revision 1.5 retrieving revision 1.6 diff -C2 -r1.5 -r1.6 *** StackViewer.py 5 Jul 2002 22:05:24 -0000 1.5 --- StackViewer.py 18 Sep 2002 03:15:56 -0000 1.6 *************** *** 1,5 **** import os import sys - import string import linecache --- 1,4 ---- *************** *** 50,54 **** funcname = code.co_name sourceline = linecache.getline(filename, lineno) ! sourceline = string.strip(sourceline) if funcname in ("?", "", None): item = "%s, line %d: %s" % (modname, lineno, sourceline) --- 49,53 ---- funcname = code.co_name sourceline = linecache.getline(filename, lineno) ! sourceline = sourceline.strip() if funcname in ("?", "", None): item = "%s, line %d: %s" % (modname, lineno, sourceline) From kbk@users.sourceforge.net Wed Sep 18 04:17:40 2002 From: kbk@users.sourceforge.net (Kurt B. Kaiser) Date: Tue, 17 Sep 2002 20:17:40 -0700 Subject: [Idle-dev] CVS: idle ToolTip.py,1.4,1.5 Message-ID: Update of /cvsroot/idlefork/idle In directory usw-pr-cvs1:/tmp/cvs-serv32167 Modified Files: ToolTip.py Log Message: Merge Py Idle changes: Rev 1.3 nnorwitz Remove unnecessary imports Index: ToolTip.py =================================================================== RCS file: /cvsroot/idlefork/idle/ToolTip.py,v retrieving revision 1.4 retrieving revision 1.5 diff -C2 -r1.4 -r1.5 *** ToolTip.py 14 Sep 2002 02:56:04 -0000 1.4 --- ToolTip.py 18 Sep 2002 03:17:38 -0000 1.5 *************** *** 4,8 **** # Ideas gleaned from PySol - import os from Tkinter import * --- 4,7 ---- From kbk@users.sourceforge.net Wed Sep 18 04:26:50 2002 From: kbk@users.sourceforge.net (Kurt B. Kaiser) Date: Tue, 17 Sep 2002 20:26:50 -0700 Subject: [Idle-dev] CVS: idle TreeWidget.py,1.3,1.4 Message-ID: Update of /cvsroot/idlefork/idle In directory usw-pr-cvs1:/tmp/cvs-serv1061 Modified Files: TreeWidget.py Log Message: Merge Py Idle changes: Rev 1.6 GvR Finally fix SF bug #441172, using a variant of patch ##443626: canceling an edit operation would not revert the value of the field. The fix takes care to destroy the Entry object, as suggested in the patch. Rev 1.7 Geiger Ho / GvR (previously applied - Idlefork Rev 1.3) Rev 1.8 doerwalter (string methods) Index: TreeWidget.py =================================================================== RCS file: /cvsroot/idlefork/idle/TreeWidget.py,v retrieving revision 1.3 retrieving revision 1.4 diff -C2 -r1.3 -r1.4 *** TreeWidget.py 27 May 2002 21:58:05 -0000 1.3 --- TreeWidget.py 18 Sep 2002 03:26:47 -0000 1.4 *************** *** 17,21 **** import os import sys - import string from Tkinter import * import imp --- 17,20 ---- *************** *** 292,295 **** --- 291,300 ---- def edit_cancel(self, event=None): + try: + entry = self.entry + del self.entry + except AttributeError: + return + entry.destroy() self.drawtext() self.canvas.focus_set() From kbk@users.sourceforge.net Wed Sep 18 04:30:14 2002 From: kbk@users.sourceforge.net (Kurt B. Kaiser) Date: Tue, 17 Sep 2002 20:30:14 -0700 Subject: [Idle-dev] CVS: idle UndoDelegator.py,1.2,1.3 Message-ID: Update of /cvsroot/idlefork/idle In directory usw-pr-cvs1:/tmp/cvs-serv2354 Modified Files: UndoDelegator.py Log Message: Merge Py Idle changes: Rev 1.4 fdrake Use string.ascii_letters instead of string.letters (SF bug #226706) Rev 1.5 doerwalter (string methods) Index: UndoDelegator.py =================================================================== RCS file: /cvsroot/idlefork/idle/UndoDelegator.py,v retrieving revision 1.2 retrieving revision 1.3 diff -C2 -r1.2 -r1.3 *** UndoDelegator.py 4 Jul 2001 03:15:10 -0000 1.2 --- UndoDelegator.py 18 Sep 2002 03:30:12 -0000 1.3 *************** *** 252,256 **** return 1 ! alphanumeric = string.letters + string.digits + "_" def classify(self, c): --- 252,256 ---- return 1 ! alphanumeric = string.ascii_letters + string.digits + "_" def classify(self, c): *************** *** 312,316 **** for cmd in self.cmds: strs.append(" " + `cmd`) ! return s + "(\n" + string.join(strs, ",\n") + "\n)" def __len__(self): --- 312,316 ---- for cmd in self.cmds: strs.append(" " + `cmd`) ! return s + "(\n" + ",\n".join(strs) + "\n)" def __len__(self): From noreply@sourceforge.net Wed Sep 18 13:35:47 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Sep 2002 05:35:47 -0700 Subject: [Idle-dev] [ idlefork-Patches-611069 ] IDLE TODO:left/right when selected text Message-ID: Patches item #611069, was opened at 2002-09-18 15:35 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=309579&aid=611069&group_id=9579 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Christos Georgiou (tzot) Assigned to: Nobody/Anonymous (nobody) Summary: IDLE TODO:left/right when selected text Initial Comment: [This was Python patch 610522, you can check that too] When text is selected and user presses left or right, the cursor moves to the correct end of the selection. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=309579&aid=611069&group_id=9579 From sebastien@anvers-smtp.planetinternet.be Wed Sep 18 13:36:29 2002 From: sebastien@anvers-smtp.planetinternet.be (sebastien@anvers-smtp.planetinternet.be) Date: 18 Sep 2002 14:36:29 +0200 Subject: [Idle-dev] l'informatique peut vous rapporter gros ! Message-ID: <20020918123609.A65D336D71@yoda.planetinternet.be> bonjour si vous voulez gagner beaucoup d'argent en peu de temps contactez-moi je me ferai un plaisir de vous envoyer les informations ceci est gratuit et sans engagement et honnete a bientot sebastien From noreply@sourceforge.net Wed Sep 18 15:20:55 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Sep 2002 07:20:55 -0700 Subject: [Idle-dev] [ idlefork-Bugs-611110 ] Integrate Macs into Config System Message-ID: Bugs item #611110, was opened at 2002-09-18 09:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=611110&group_id=9579 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Kurt B. Kaiser (kbk) Assigned to: Nobody/Anonymous (nobody) Summary: Integrate Macs into Config System Initial Comment: Python-idle config-mac.txt needs to be integrated into the new configuration system. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=611110&group_id=9579 From kbk@shore.net Wed Sep 18 15:53:20 2002 From: kbk@shore.net (Kurt B. Kaiser) Date: 18 Sep 2002 10:53:20 -0400 Subject: [Idle-dev] Stephen M. Gava Design Notes In-Reply-To: <1031705071.698.156.camel@oberon> Message-ID: The following is Idlefork design information supplied by Stephen M. Gava. It includes remarks on further development of his configuration system which I believe should be archived on Idle-dev. Thanks again to Stephen for his work and for these notes. KBK "Stephen M. Gava" writes: [...] > My config system work > ===================== > > My work on the config back and front ends is complete to a working > first cut level. Likely there are arbitrary decisions I made about how > to do many particular things that were not the best possible ones but > there you go, there were always reasons though. > > The main issues I can think of off the top of my head that might still > need looking at are as follows. > > Input checking > -------------- > > There are a couple of minor areas remaining where checking for sensible > user inputs might make sense. the only one I can think of off the top of > my head is the initial window width and height setting. > > Keymapping bugs > --------------- > > There seems to be on ongoing issue (in all idle versions) where certain > editing keystrokes cannot be remapped properly in the text control. I've > attempted to solve that in a couple of ways in the new keymapping stuff > but have unconfirmed reports that there might still be a problem. If so > I think it might have something to do with needing to successfully > override the text control's default tk editing bindings. > > Extension API changes > --------------------- > > There have been minor changes to the way idle extensions interface with > idle proper, mainly regarding keymapping. (As a result of Guido's > agreement on needing to dispense with the old hard-coded "windows and > unix only" keymappings approach.) I alway meant to document this with a > quick note pointing out the differences at the top of extend.txt, but I > hadn't got around to it yet. The changes are documented at the top of > the new config-extensions.def . From noreply@sourceforge.net Wed Sep 18 18:06:49 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Sep 2002 10:06:49 -0700 Subject: [Idle-dev] [ idlefork-Bugs-611110 ] Integrate Macs into Config System Message-ID: Bugs item #611110, was opened at 2002-09-18 14:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=611110&group_id=9579 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Kurt B. Kaiser (kbk) >Assigned to: Tony Lownds (tonylownds) Summary: Integrate Macs into Config System Initial Comment: Python-idle config-mac.txt needs to be integrated into the new configuration system. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=611110&group_id=9579 From kbk@users.sourceforge.net Wed Sep 18 18:07:08 2002 From: kbk@users.sourceforge.net (Kurt B. Kaiser) Date: Wed, 18 Sep 2002 10:07:08 -0700 Subject: [Idle-dev] CVS: idle PyShell.py,1.25,1.26 Message-ID: Update of /cvsroot/idlefork/idle In directory usw-pr-cvs1:/tmp/cvs-serv8980 Modified Files: PyShell.py Log Message: Merge Py Idle changes: Missed adding "import types" while merging PyShell by hand.... Index: PyShell.py =================================================================== RCS file: /cvsroot/idlefork/idle/PyShell.py,v retrieving revision 1.25 retrieving revision 1.26 diff -C2 -r1.25 -r1.26 *** PyShell.py 18 Sep 2002 02:29:59 -0000 1.25 --- PyShell.py 18 Sep 2002 17:07:05 -0000 1.26 *************** *** 8,13 **** import socket import time - import warnings import traceback import linecache --- 8,14 ---- import socket import time import traceback + import types + import warnings import linecache From kbk@users.sourceforge.net Wed Sep 18 18:30:39 2002 From: kbk@users.sourceforge.net (Kurt B. Kaiser) Date: Wed, 18 Sep 2002 10:30:39 -0700 Subject: [Idle-dev] CVS: idle config-mac.txt,1.1.3.1,NONE Message-ID: Update of /cvsroot/idlefork/idle In directory usw-pr-cvs1:/tmp/cvs-serv17107 Removed Files: config-mac.txt Log Message: Merge Py Idle: Removing config-mac.txt, not used in Idlefork --- config-mac.txt DELETED --- From kbk@shore.net Wed Sep 18 18:55:52 2002 From: kbk@shore.net (Kurt B. Kaiser) Date: 18 Sep 2002 13:55:52 -0400 Subject: [Idle-dev] ANNOUNCE -- Python-idle to Idlefork Merge Completed Message-ID: Python-idle has been merged into Idlefork as of 13 Sep 2002. I believe there are no Python-idle check-ins after that date, and since there will not be any future check-ins this should be the final merge from Python-idle. The Idlefork CVS is again open for business! Please submit bugs and patches to the Idlefork Tracker and any comments to the Idle-dev list. KBK From noreply@sourceforge.net Wed Sep 18 19:51:10 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Sep 2002 11:51:10 -0700 Subject: [Idle-dev] [ idlefork-Bugs-611225 ] idle.pyw has "import IdleConf" Message-ID: Bugs item #611225, was opened at 2002-09-18 20:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=611225&group_id=9579 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Hernan Martinez Foffani (hfoffani) Assigned to: Nobody/Anonymous (nobody) Summary: idle.pyw has "import IdleConf" Initial Comment: well, that. sorry, no patch. i'm on a win2k pc with no tools. -Hernan ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=611225&group_id=9579 From noreply@sourceforge.net Wed Sep 18 20:40:20 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Wed, 18 Sep 2002 12:40:20 -0700 Subject: [Idle-dev] [ idlefork-Bugs-611225 ] idle.pyw has "import IdleConf" Message-ID: Bugs item #611225, was opened at 2002-09-18 20:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=611225&group_id=9579 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Hernan Martinez Foffani (hfoffani) Assigned to: Nobody/Anonymous (nobody) >Summary: idle.pyw has "import IdleConf" Initial Comment: well, that. sorry, no patch. i'm on a win2k pc with no tools. -Hernan ---------------------------------------------------------------------- >Comment By: Hernan Martinez Foffani (hfoffani) Date: 2002-09-18 21:40 Message: Logged In: YES user_id=112690 of course I mean in CVS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=611225&group_id=9579 From noreply@sourceforge.net Thu Sep 19 09:21:46 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Sep 2002 01:21:46 -0700 Subject: [Idle-dev] [ idlefork-Bugs-611473 ] IDLE does not work with Python 2.2 Message-ID: Bugs item #611473, was opened at 2002-09-19 10:21 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=611473&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: IDLE does not work with Python 2.2 Initial Comment: In EditorWindow.py, IDLE refers to False, which is not available in Python 2.2. In http://mail.python.org/pipermail/python-dev/2002-September/028782.html Guido rules that support for Python 2.2 is essential, so I think this is a bug. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=611473&group_id=9579 From noreply@sourceforge.net Thu Sep 19 14:30:07 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Sep 2002 06:30:07 -0700 Subject: [Idle-dev] [ idlefork-Bugs-611473 ] IDLE does not work with Python 2.2 Message-ID: Bugs item #611473, was opened at 2002-09-19 04:21 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=611473&group_id=9579 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. Löwis (loewis) >Assigned to: Kurt B. Kaiser (kbk) Summary: IDLE does not work with Python 2.2 Initial Comment: In EditorWindow.py, IDLE refers to False, which is not available in Python 2.2. In http://mail.python.org/pipermail/python-dev/2002-September/028782.html Guido rules that support for Python 2.2 is essential, so I think this is a bug. ---------------------------------------------------------------------- >Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-19 09:30 Message: Logged In: YES user_id=6380 Hm, 2.2.1 has True and False. When I said "2.2" I didn't mean the initial 2.2 release, I meant "some release in the 2.2 family". Requiring 2.2.1 is fine with me. But it's up to Kurt. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=611473&group_id=9579 From noreply@sourceforge.net Thu Sep 19 15:37:00 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Sep 2002 07:37:00 -0700 Subject: [Idle-dev] [ idlefork-Patches-610763 ] Extension to Calltips / Show attributes Message-ID: Patches item #610763, was opened at 2002-09-17 15:16 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=309579&aid=610763&group_id=9579 Category: None Group: None Status: Open >Resolution: Accepted Priority: 5 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: Extension to Calltips / Show attributes Initial Comment: See http://python.org/sf/525109 just don't want to lose track of it, if it's desirable in idlefork. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2002-09-19 09:36 Message: Logged In: YES user_id=149084 >From Martin Liebman's Python-idle patch: "Extension to Calltips / Show attributes The attached files (unified diff files) implement a (quick and dirty but usefull) extension to IDLE 0.8 (Python 2.2) - Tested on WINDOWS 95/98/NT/2000 - Similar to "CallTips" this extension shows (context sensitive) all available member functions and attributes of the current object after hitting the 'dot'-key. The toplevel help widget now supports scrolling. (Key- Up and Key-Down events) ...that is why I changed among else the first argument of 'showtip' from 'text string' to a 'list of text strings' ... The 'space'-key is used to insert the topmost item of the help widget into an IDLE text window. ...the even handling seems to be a critical part of the current IDLE implementation. That is why I added the new functionallity as a patch of CallTips.py and CallTipWindow.py. May be you still have a better implementation ... Greetings Martin Liebmann " See also Idle-dev 02Mar02. Files left on Python Patches for now. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=309579&aid=610763&group_id=9579 From noreply@sourceforge.net Thu Sep 19 16:10:09 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Sep 2002 08:10:09 -0700 Subject: [Idle-dev] [ idlefork-Bugs-611473 ] IDLE does not work with Python 2.2 Message-ID: Bugs item #611473, was opened at 2002-09-19 03:21 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=611473&group_id=9579 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Kurt B. Kaiser (kbk) Summary: IDLE does not work with Python 2.2 Initial Comment: In EditorWindow.py, IDLE refers to False, which is not available in Python 2.2. In http://mail.python.org/pipermail/python-dev/2002-September/028782.html Guido rules that support for Python 2.2 is essential, so I think this is a bug. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2002-09-19 10:10 Message: Logged In: YES user_id=149084 Since my code is full of Bool I'm inclined to go with requiring 2.2.1, the bug fix release everyone is using anyway (right?). Per GvR +1 I'm moving back to 2.2.1 myself and would rather not go to 2.2. But it's not a big deal either way, about 30 lines of code. I'll post a note to the list and in the absence of strenuous objection I'd recommend closing this as rejected. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-19 08:30 Message: Logged In: YES user_id=6380 Hm, 2.2.1 has True and False. When I said "2.2" I didn't mean the initial 2.2 release, I meant "some release in the 2.2 family". Requiring 2.2.1 is fine with me. But it's up to Kurt. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=611473&group_id=9579 From kbk@shore.net Thu Sep 19 17:29:46 2002 From: kbk@shore.net (Kurt B. Kaiser) Date: 19 Sep 2002 12:29:46 -0400 Subject: [Idle-dev] Idlefork Requires Python 2.2.1? Message-ID: You may have noticed some comments going by this morning relative to the use of the bool type in Idlefork. The merge from Python-idle introduced some code which uses the new constants, and I have used them a bit also in my code. The bool type was introduced in the Python 2.2.1 "bugfix" release with the comment "- Added new builtin function bool() and new builtin constants True and False to ease backporting of code developed for Python 2.3. In 2.2, bool() returns 1 or 0, True == 1, and False == 0." I'm planning on switching back to 2.2 for testing purposes, and I'd rather use the 2.2.1 bugfix release than 2.2. If there is no strenuous objection from the list I'd like to make Python 2.2.1 or later a dependency for Idlefork. KBK From pobrien@orbtech.com Thu Sep 19 17:56:28 2002 From: pobrien@orbtech.com (Patrick K. O'Brien) Date: Thu, 19 Sep 2002 11:56:28 -0500 Subject: [Idle-dev] Idlefork Requires Python 2.2.1? In-Reply-To: Message-ID: [Kurt B. Kaiser] > > If there is no strenuous objection from the list I'd like to make > Python 2.2.1 or later a dependency for Idlefork. I'm strongly in favor of 2.2.1 as the minimum dependency. Pat -- Patrick K. O'Brien Orbtech ----------------------------------------------- "Your source for Python programming expertise." ----------------------------------------------- Web: http://www.orbtech.com/web/pobrien/ Blog: http://www.orbtech.com/blog/pobrien/ Wiki: http://www.orbtech.com/wiki/PatrickOBrien ----------------------------------------------- From kbk@users.sourceforge.net Thu Sep 19 20:54:58 2002 From: kbk@users.sourceforge.net (Kurt B. Kaiser) Date: Thu, 19 Sep 2002 12:54:58 -0700 Subject: [Idle-dev] CVS: idle idle.pyw,1.2,1.3 Message-ID: Update of /cvsroot/idlefork/idle In directory usw-pr-cvs1:/tmp/cvs-serv31429 Modified Files: idle.pyw Log Message: SF Bug #611225. Bring idle.pyw into alignment with idle.py, eliminate calling deleted module IdleConf.py Index: idle.pyw =================================================================== RCS file: /cvsroot/idlefork/idle/idle.pyw,v retrieving revision 1.2 retrieving revision 1.3 diff -C2 -r1.2 -r1.3 *** idle.pyw 4 Jul 2001 03:15:10 -0000 1.2 --- idle.pyw 19 Sep 2002 19:54:55 -0000 1.3 *************** *** 1,12 **** #! /usr/bin/env python - import os - import sys - import IdleConf - - idle_dir = os.path.split(sys.argv[0])[0] - IdleConf.load(idle_dir) - - # defer importing Pyshell until IdleConf is loaded import PyShell PyShell.main() --- 1,4 ---- From noreply@sourceforge.net Thu Sep 19 21:04:52 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Sep 2002 13:04:52 -0700 Subject: [Idle-dev] [ idlefork-Bugs-611225 ] idle.pyw has "import IdleConf" Message-ID: Bugs item #611225, was opened at 2002-09-18 13:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=611225&group_id=9579 Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Hernan Martinez Foffani (hfoffani) >Assigned to: Kurt B. Kaiser (kbk) >Summary: idle.pyw has "import IdleConf" Initial Comment: well, that. sorry, no patch. i'm on a win2k pc with no tools. -Hernan ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2002-09-19 15:04 Message: Logged In: YES user_id=149084 Checked in a fix ---------------------------------------------------------------------- Comment By: Hernan Martinez Foffani (hfoffani) Date: 2002-09-18 14:40 Message: Logged In: YES user_id=112690 of course I mean in CVS. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=611225&group_id=9579 From noreply@sourceforge.net Thu Sep 19 21:24:10 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 19 Sep 2002 13:24:10 -0700 Subject: [Idle-dev] [ idlefork-Bugs-441472 ] Non-latin1 encodings under Windows. Message-ID: Bugs item #441472, was opened at 2001-07-15 12:48 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=441472&group_id=9579 Category: None Group: None Status: Open >Resolution: Fixed Priority: 5 Submitted By: Patrick K. O'Brien (pobrien) Assigned to: Nobody/Anonymous (nobody) Summary: Non-latin1 encodings under Windows. Initial Comment: The attached problem description was submitted to the python list by Roman Suzi. The problem involves internationalization issues and non-latin1 characters under Windows. The problem is described in great detail and solutions are provided. This should probably be a high priority item for the IDLE revitalization effort. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2002-09-19 15:24 Message: Logged In: YES user_id=149084 Since the merge with Python-idle which includes PEP 263 it would seem that this issue is resolved. I'm going to try sending a copy of the Syncmail to Roman Suzi. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-05-20 19:18 Message: Logged In: YES user_id=6380 How old is that email? The FixTk.py problem has been fixed in Python 2.2. I hope that someone will fix the Unicode handling in _tkinter.c and submit a patch to the Python patch manager. Otherwise this will never get fixed. (The regular maintainer of _tkinter.c has no access to systems where foreign encodings are used for testing.) I don't understand why the default encoding must be changed. If the user enters non-ASCII characters Tcl will automatically produce Unicode. If the issue is that there are source code files encoded in national encoding, please wait for PEP 263 -- IDLE should be patched to support the same convention. ---------------------------------------------------------------------- Comment By: Stephen M. Gava (elguavas) Date: 2002-05-19 22:05 Message: Logged In: YES user_id=75867 Should/has this be(een) adressed in python idle? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=441472&group_id=9579 From noreply@sourceforge.net Sun Sep 22 18:44:13 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 22 Sep 2002 10:44:13 -0700 Subject: [Idle-dev] [ idlefork-Bugs-612886 ] copy/paste menu items fail Message-ID: Bugs item #612886, was opened at 2002-09-22 19:44 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=612886&group_id=9579 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Hernan Martinez Foffani (hfoffani) Assigned to: Nobody/Anonymous (nobody) Summary: copy/paste menu items fail Initial Comment: The Edit/Cut, Edit/Copy Edit/Paste menu items are not working. Neither are the shortcuts keys unless they are the same as the OS default. Windows 2K Python 2.2.1 IDLEfork from CVS Sept 19 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=612886&group_id=9579 From noreply@sourceforge.net Mon Sep 23 01:23:23 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 22 Sep 2002 17:23:23 -0700 Subject: [Idle-dev] [ idlefork-Bugs-612886 ] copy/paste menu items fail Message-ID: Bugs item #612886, was opened at 2002-09-22 12:44 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=612886&group_id=9579 Category: None Group: None Status: Open >Resolution: Accepted >Priority: 8 Submitted By: Hernan Martinez Foffani (hfoffani) Assigned to: Nobody/Anonymous (nobody) Summary: copy/paste menu items fail Initial Comment: The Edit/Cut, Edit/Copy Edit/Paste menu items are not working. Neither are the shortcuts keys unless they are the same as the OS default. Windows 2K Python 2.2.1 IDLEfork from CVS Sept 19 ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2002-09-22 19:23 Message: Logged In: YES user_id=149084 Confirmed with Linux/Gnome ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=612886&group_id=9579 From noreply@sourceforge.net Mon Sep 23 01:28:24 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 22 Sep 2002 17:28:24 -0700 Subject: [Idle-dev] [ idlefork-Bugs-611473 ] IDLE does not work with Python 2.2 Message-ID: Bugs item #611473, was opened at 2002-09-19 03:21 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=611473&group_id=9579 Category: None Group: None >Status: Closed Resolution: None Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Kurt B. Kaiser (kbk) Summary: IDLE does not work with Python 2.2 Initial Comment: In EditorWindow.py, IDLE refers to False, which is not available in Python 2.2. In http://mail.python.org/pipermail/python-dev/2002-September/028782.html Guido rules that support for Python 2.2 is essential, so I think this is a bug. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2002-09-22 19:28 Message: Logged In: YES user_id=149084 No objection from Idle-dev to closing this bug. Bool type ok for Idle/Python 2.2.1 ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2002-09-19 10:10 Message: Logged In: YES user_id=149084 Since my code is full of Bool I'm inclined to go with requiring 2.2.1, the bug fix release everyone is using anyway (right?). Per GvR +1 I'm moving back to 2.2.1 myself and would rather not go to 2.2. But it's not a big deal either way, about 30 lines of code. I'll post a note to the list and in the absence of strenuous objection I'd recommend closing this as rejected. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-19 08:30 Message: Logged In: YES user_id=6380 Hm, 2.2.1 has True and False. When I said "2.2" I didn't mean the initial 2.2 release, I meant "some release in the 2.2 family". Requiring 2.2.1 is fine with me. But it's up to Kurt. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=611473&group_id=9579 From noreply@sourceforge.net Mon Sep 23 01:28:30 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 22 Sep 2002 17:28:30 -0700 Subject: [Idle-dev] [ idlefork-Bugs-611473 ] IDLE does not work with Python 2.2 Message-ID: Bugs item #611473, was opened at 2002-09-19 03:21 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=611473&group_id=9579 Category: None Group: None Status: Closed Resolution: None Priority: 5 Submitted By: Martin v. Löwis (loewis) Assigned to: Kurt B. Kaiser (kbk) Summary: IDLE does not work with Python 2.2 Initial Comment: In EditorWindow.py, IDLE refers to False, which is not available in Python 2.2. In http://mail.python.org/pipermail/python-dev/2002-September/028782.html Guido rules that support for Python 2.2 is essential, so I think this is a bug. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2002-09-22 19:28 Message: Logged In: YES user_id=149084 No objection from Idle-dev to closing this bug. Bool type ok for Idle/Python 2.2.1 ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2002-09-22 19:28 Message: Logged In: YES user_id=149084 No objection from Idle-dev to closing this bug. Bool type ok for Idle/Python 2.2.1 ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2002-09-19 10:10 Message: Logged In: YES user_id=149084 Since my code is full of Bool I'm inclined to go with requiring 2.2.1, the bug fix release everyone is using anyway (right?). Per GvR +1 I'm moving back to 2.2.1 myself and would rather not go to 2.2. But it's not a big deal either way, about 30 lines of code. I'll post a note to the list and in the absence of strenuous objection I'd recommend closing this as rejected. ---------------------------------------------------------------------- Comment By: Guido van Rossum (gvanrossum) Date: 2002-09-19 08:30 Message: Logged In: YES user_id=6380 Hm, 2.2.1 has True and False. When I said "2.2" I didn't mean the initial 2.2 release, I meant "some release in the 2.2 family". Requiring 2.2.1 is fine with me. But it's up to Kurt. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=611473&group_id=9579 From noreply@sourceforge.net Mon Sep 23 01:38:38 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 22 Sep 2002 17:38:38 -0700 Subject: [Idle-dev] [ idlefork-Bugs-613006 ] Ctrl-x Unix Binding Clears Selection Message-ID: Bugs item #613006, was opened at 2002-09-22 19:38 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=613006&group_id=9579 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Kurt B. Kaiser (kbk) Assigned to: Nobody/Anonymous (nobody) Summary: Ctrl-x Unix Binding Clears Selection Initial Comment: Example: I wish to open the module PyShell. I have a module open in an edit window and I highlight PyShell in "import PyShell" When I press Ctrl-x (to be followed by Ctrl-m) the highlighted text is erased. (Undo will restore it.) Ctrl-x works correctly in Python-idle. Linux/Gnome. CVS MAIN as of today. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=613006&group_id=9579 From noreply@sourceforge.net Mon Sep 23 01:39:54 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 22 Sep 2002 17:39:54 -0700 Subject: [Idle-dev] [ idlefork-Bugs-612886 ] copy/paste menu items fail Message-ID: Bugs item #612886, was opened at 2002-09-22 19:44 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=612886&group_id=9579 Category: None Group: None Status: Open Resolution: Accepted Priority: 8 Submitted By: Hernan Martinez Foffani (hfoffani) Assigned to: Nobody/Anonymous (nobody) Summary: copy/paste menu items fail Initial Comment: The Edit/Cut, Edit/Copy Edit/Paste menu items are not working. Neither are the shortcuts keys unless they are the same as the OS default. Windows 2K Python 2.2.1 IDLEfork from CVS Sept 19 ---------------------------------------------------------------------- Comment By: Josh Robb (josh_robb) Date: 2002-09-23 02:39 Message: Logged In: YES user_id=614376 I have noticed that BicycleRepairMan_Idle.py is not working with CVS idle. The extension loads but menu items do not work. Also my own idle extensions do not have their event's fire (as defined in config-extensions.def) unless they also have keybindings defined. I have been meaning to look at this but have enough other things right now. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2002-09-23 02:23 Message: Logged In: YES user_id=149084 Confirmed with Linux/Gnome ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=612886&group_id=9579 From noreply@sourceforge.net Mon Sep 23 01:45:31 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 22 Sep 2002 17:45:31 -0700 Subject: [Idle-dev] [ idlefork-Patches-567216 ] shell window binding cleanup Message-ID: Patches item #567216, was opened at 2002-06-10 23:52 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=309579&aid=567216&group_id=9579 Category: None Group: None >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Stephen M. Gava (elguavas) >Assigned to: Kurt B. Kaiser (kbk) Summary: shell window binding cleanup Initial Comment: this is a todo reminder. the following patch was applied to python idle a while back, something like this needs to be done in idlfork too but exactly what will depend on how the shell/output window restructure is handled: =========== Update of /cvsroot/python/python/dist/src/Tools/idle In directory usw-pr-cvs1:/tmp/cvs-serv32112 Modified Files: EditorWindow.py PyShell.py ScriptBinding.py Log Message: Patch 543222. Disable script bindings in shell window. Index: EditorWindow.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Tools/idle/EditorWindow.py,v retrieving revision 1.41 retrieving revision 1.42 diff -C2 -d -r1.41 -r1.42 *** EditorWindow.py 14 Apr 2002 10:30:51 -0000 1.41 --- EditorWindow.py 21 May 2002 17:00:19 -0000 1.42 *************** *** 96,99 **** --- 96,100 ---- vars = {} + runnable = False # Shell window cannot Import Module or Run Script def __init__(self, flist=None, filename=None, key=None, root=None): Index: PyShell.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Tools/idle/PyShell.py,v retrieving revision 1.36 retrieving revision 1.37 diff -C2 -d -r1.36 -r1.37 *** PyShell.py 4 Apr 2002 22:55:58 -0000 1.36 --- PyShell.py 21 May 2002 17:00:20 -0000 1.37 *************** *** 77,80 **** --- 77,81 ---- # Regular text edit window when a shell is present # XXX ought to merge with regular editor window + runnable = True # Shell not present, enable Import Module and Run Script def __init__(self, *args): Index: ScriptBinding.py =================================================================== RCS file: /cvsroot/python/python/dist/src/Tools/idle/ScriptBinding.py,v retrieving revision 1.11 retrieving revision 1.12 diff -C2 -d -r1.11 -r1.12 *** ScriptBinding.py 7 Aug 2001 17:15:36 -0000 1.11 --- ScriptBinding.py 21 May 2002 17:00:20 -0000 1.12 *************** *** 52,55 **** --- 52,58 ---- def __init__(self, editwin): + if not editwin.runnable: + self.menudefs = [] + self.keydefs = {} self.editwin = editwin # Provide instance variables referenced by Debugger ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2002-09-22 19:45 Message: Logged In: YES user_id=149084 Done differently in MAIN branch. Shell can't import, run, or format. Menu items removed. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=309579&aid=567216&group_id=9579 From noreply@sourceforge.net Mon Sep 23 01:54:34 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 22 Sep 2002 17:54:34 -0700 Subject: [Idle-dev] [ idlefork-Patches-456006 ] open multiple modules at once Message-ID: Patches item #456006, was opened at 2001-08-27 23:11 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=309579&aid=456006&group_id=9579 Category: None Group: None Status: Open Resolution: Postponed >Priority: 3 Submitted By: Stephen M. Gava (elguavas) Assigned to: Stephen M. Gava (elguavas) Summary: open multiple modules at once Initial Comment: Every time I open a project, I open a lot of modules, and this was usually done by double-clicking each module in import myModule1, myModule2, myModule3, myModule4, myModule5, myModule6 and pressing Alt-M to open it. Now I patched EditorWindow.py to extend the ability of open_module to open a list of modules (and ignore the import keyword), so that one can select the whole line and open all modules with one Alt-M. Below is the changed method open_module in EditorWindow.py, which can be substituted to the original to obtain the new behaviour. def open_module(self, event=None): # XXX Shouldn't this be in IOBinding or in FileList? try: name = self.text.get("sel.first", "sel.last") except TclError: name = "" else: name = string.strip(name) if not name: name = tkSimpleDialog.askstring("Module", "Enter the name of a Python module\n" "to search on sys.path and open:", parent=self.text) name = string.replace(name, ",", " ") name = string.replace(name, ";", " ") nameList = string.split(name) # XXX Ought to support package syntax # XXX Ought to insert current file's directory in front of path for name in nameList: if name in ["", "import"]: continue try: (f, file, (suffix, mode, type)) = imp.find_module(name) except (NameError, ImportError), msg: tkMessageBox.showerror("Import error", str(msg), parent=self.text) return if type != imp.PY_SOURCE: tkMessageBox.showerror("Unsupported type", "%s is not a source module" % name, parent=self.text) return if f: f.close() if self.flist: self.flist.open(file) else: self.io.loadfile(file) Daniel Haertle ------------------------------------------------------------------------ Daniel Haertle haertle@iqe.phys.ethz.ch _________________ ___ http://www.nlo.ethz.ch / ____/_ __/ /_/ / ETH Hoenggerberg - Nonlinear Optics Laboratory / __/_ / / / __ / Institute of Quantum Electronics, HPF E18 /______/ /__/ /__/ /__/ 8093 Zuerich - Switzerland Tel +41 1 63 32338 Fax +41 1 63 31056 ------------------------------------------------------------------------ ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2002-09-22 19:54 Message: Logged In: YES user_id=149084 Per GvR Python style guide, PEP 8, multiple module names on one line are discouraged. The sylistically allowable exceptions are rather minor. Downgrade priority pending further discussion whether this is worthwhile. ---------------------------------------------------------------------- Comment By: Stephen M. Gava (elguavas) Date: 2001-10-07 21:59 Message: Logged In: YES user_id=75867 I like this idea in principle. I float implementation detail ideas on idle-dev when I get the chance to eventually come back to this in earnest. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=309579&aid=456006&group_id=9579 From tonylownds@users.sourceforge.net Mon Sep 23 01:57:13 2002 From: tonylownds@users.sourceforge.net (Tony Lownds) Date: Sun, 22 Sep 2002 17:57:13 -0700 Subject: [Idle-dev] CVS: idle config-keys.def,1.11,1.12 Message-ID: Update of /cvsroot/idlefork/idle In directory usw-pr-cvs1:/tmp/cvs-serv9963 Modified Files: config-keys.def Log Message: Added new standard keybinding set for Macs. Index: config-keys.def =================================================================== RCS file: /cvsroot/idlefork/idle/config-keys.def,v retrieving revision 1.11 retrieving revision 1.12 diff -C2 -r1.11 -r1.12 *** config-keys.def 14 Sep 2002 03:18:43 -0000 1.11 --- config-keys.def 23 Sep 2002 00:57:10 -0000 1.12 *************** *** 100,101 **** --- 100,146 ---- toggle-tabs= change-indentwidth= + [IDLE Classic Mac] + copy= + cut= + paste= + beginning-of-line= + center-insert= + close-all-windows= + close-window= + end-of-file= + python-docs= + python-context-help= + history-next= + history-previous= + interrupt-execution= + open-class-browser= + open-module= + open-new-window= + open-window-from-file= + plain-newline-and-indent= + print-window= + redo= + remove-selection= + save-window-as-file= + save-window= + save-copy-of-window-as-file= + select-all= + toggle-auto-coloring= + undo= + find= + find-again= + find-in-files= + find-selection= + replace= + goto-line= + smart-backspace= + newline-and-indent= + smart-indent= + indent-region= + dedent-region= + comment-region= + uncomment-region= + tabify-region= + untabify-region= + toggle-tabs= + change-indentwidth= From noreply@sourceforge.net Mon Sep 23 01:58:13 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 22 Sep 2002 17:58:13 -0700 Subject: [Idle-dev] [ idlefork-Patches-451088 ] RemoteInterpreter patch to run on win32 Message-ID: Patches item #451088, was opened at 2001-08-15 02:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=309579&aid=451088&group_id=9579 Category: None Group: None >Status: Closed >Resolution: Out of Date Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Stephen M. Gava (elguavas) Summary: RemoteInterpreter patch to run on win32 Initial Comment: *** ../Tools/idlefork-0.8.1/RemoteInterp.py Thu Jul 12 17:06:22 2001 --- ../Tools/idlenew/RemoteInterp.py Wed Aug 15 15:05:10 2001 *************** *** 121,127 **** def _decode_msg(self, msg): seqno = self.decode_seqno(msg [:self.SEQNO_ENC_LEN]) msg = msg[self.SEQNO_ENC_LEN:] ! parts = msg.split(" ", 2) if len(parts) == 1: cmd = msg arg = '' --- 121,131 ---- def _decode_msg(self, msg): seqno = self.decode_seqno(msg [:self.SEQNO_ENC_LEN]) msg = msg[self.SEQNO_ENC_LEN:] ! # ! # split a message into two parts ! # cmd arg ! # ! parts = msg.split(" ", 1) if len(parts) == 1: cmd = msg arg = '' *************** *** 263,280 **** self._cmd.reply() self._cmd.close() def startRemoteInterp(id): import os # UNIX domain sockets are simpler for starters sock = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM) ! sock.bind("/var/tmp/ri.%s" % id) try: sock.listen(1) cli, addr = sock.accept() rinterp = RemoteInterp(cli) rinterp.run() finally: ! os.unlink("/var/tmp/ri.%s" % id) class RIClient: """Client of the remote interpreter""" --- 267,299 ---- self._cmd.reply() self._cmd.close() + def getAddress(id): + """returns a string representing the address of the + Unix domain socket for a particular id""" + import tempfile + import os + if tempfile.tempdir: + filename = os.path.join (tempfile.tempdir, "rs.%s" % id) + else: + # + # no temp dir defined in environment, use the + # current directory. + # + filename = "rs.%s" % id + return filename + def startRemoteInterp(id): import os # UNIX domain sockets are simpler for starters sock = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM) ! sock.bind( getAddress(id) ) try: sock.listen(1) cli, addr = sock.accept() rinterp = RemoteInterp(cli) rinterp.run() finally: ! os.unlink( getAddress(id) ) class RIClient: """Client of the remote interpreter""" *************** *** 317,328 **** def riExec(id, file): sock = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM) ! sock.connect("/var/tmp/ri.%s" % id) cli = RIClient(sock) cli.execfile(file) cli.run() if __name__ == "__main__": import sys import getopt --- 336,360 ---- def riExec(id, file): sock = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM) ! sock.connect(getAddress(id)) cli = RIClient(sock) cli.execfile(file) cli.run() if __name__ == "__main__": + + # Usage: + # python RemoteInterp.py [-c] [-v] id + # Options: + # -c run as a client. Otherwise, run as a server by default + # -v verbose mode + # Example: + # This starts the server: + # python RemoteInterp.py id123 + # + # This starts the client: + # python RemoteInterp.py -c id123 test.py + # import sys import getopt ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2002-09-22 19:58 Message: Logged In: YES user_id=149084 RemoteInterpreter module has been eliminated from the current version of Idle running GvR RPC. Revisit patch code if there is a problem running GRPC on Windows. Close for now. ---------------------------------------------------------------------- Comment By: Stephen M. Gava (elguavas) Date: 2001-10-07 21:56 Message: Logged In: YES user_id=75867 this will have to wait until I can get someone to work on the remote execution aspects of idle fork. if that has to be me then it won't be for some time. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=309579&aid=451088&group_id=9579 From tonylownds@users.sourceforge.net Mon Sep 23 02:01:22 2002 From: tonylownds@users.sourceforge.net (Tony Lownds) Date: Sun, 22 Sep 2002 18:01:22 -0700 Subject: [Idle-dev] CVS: idle IOBinding.py,1.8,1.9 Message-ID: Update of /cvsroot/idlefork/idle In directory usw-pr-cvs1:/tmp/cvs-serv10880 Modified Files: IOBinding.py Log Message: Work around Mac OS X platform encoding issues. Index: IOBinding.py =================================================================== RCS file: /cvsroot/idlefork/idle/IOBinding.py,v retrieving revision 1.8 retrieving revision 1.9 diff -C2 -r1.8 -r1.9 *** IOBinding.py 16 Sep 2002 22:03:37 -0000 1.8 --- IOBinding.py 23 Sep 2002 01:01:20 -0000 1.9 *************** *** 66,69 **** --- 66,72 ---- # these problems, falling back to ASCII encoding = locale.nl_langinfo(locale.CODESET) + if encoding is None: + # situation occurs on Mac OS X + encoding = 'ascii' codecs.lookup(encoding) except (NameError, AttributeError, LookupError): *************** *** 73,76 **** --- 76,82 ---- try: encoding = locale.getdefaultlocale()[1] + if encoding is None: + # situation occurs on Mac OS X + encoding = 'ascii' codecs.lookup(encoding) except (ValueError, LookupError): From noreply@sourceforge.net Mon Sep 23 02:03:57 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 22 Sep 2002 18:03:57 -0700 Subject: [Idle-dev] [ idlefork-Patches-450784 ] Immediate button for Debugger Message-ID: Patches item #450784, was opened at 2001-08-14 07:52 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=309579&aid=450784&group_id=9579 Category: None Group: None Status: Open >Resolution: Later Priority: 5 Submitted By: Michael Dubner (dubnerm) >Assigned to: Kurt B. Kaiser (kbk) Summary: Immediate button for Debugger Initial Comment: This patch adds to IDLE debugger button that allows to check current state of local and global dictionaries not only on top level (as in debugger window) it can be used to change values also (__dbg_locals__ and __dbg_globals__ variables created). You should note that this is some sort of "cheat" - i'm using standard "code" module on top of IDLE console. Use this at your own risk. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2002-09-22 20:03 Message: Logged In: YES user_id=149084 Idle debugger currently allows viewing local and global variables but doesn't have the (desirable) functionality to change them. Will evaluate the patch but may do it differently. Pdb ability to move up and down the stack sets a good example for this functionality. ---------------------------------------------------------------------- Comment By: Stephen M. Gava (elguavas) Date: 2001-10-07 21:52 Message: Logged In: YES user_id=75867 this possible feature would be impacted by the remote execution implementation that is ultimately chosen. hold until that is in place. ---------------------------------------------------------------------- Comment By: Michael Dubner (dubnerm) Date: 2001-08-14 08:13 Message: Logged In: YES user_id=39274 Note that Debugger.0.8.imm.0.2.patch can be applied to any version of IDLE debugger from 0.6 to 0.8.1 (it had not changed for long time) ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=309579&aid=450784&group_id=9579 From tonylownds@users.sourceforge.net Mon Sep 23 02:04:07 2002 From: tonylownds@users.sourceforge.net (Tony Lownds) Date: Sun, 22 Sep 2002 18:04:07 -0700 Subject: [Idle-dev] CVS: idle CallTipWindow.py,1.4,1.5 Message-ID: Update of /cvsroot/idlefork/idle In directory usw-pr-cvs1:/tmp/cvs-serv11447 Modified Files: CallTipWindow.py Log Message: Work around Mac OS X transient window issues Index: CallTipWindow.py =================================================================== RCS file: /cvsroot/idlefork/idle/CallTipWindow.py,v retrieving revision 1.4 retrieving revision 1.5 diff -C2 -r1.4 -r1.5 *** CallTipWindow.py 15 Sep 2002 21:43:13 -0000 1.4 --- CallTipWindow.py 23 Sep 2002 01:04:05 -0000 1.5 *************** *** 30,33 **** --- 30,41 ---- tw.wm_overrideredirect(1) tw.wm_geometry("+%d+%d" % (x, y)) + try: + # This command is only needed and available on Tk >= 8.4.0 for OSX + # Without it, call tips intrude on the typing process by grabbing + # the focus. + tw.tk.call("::tk::unsupported::MacWindowStyle", "style", tw._w, + "help", "noActivates") + except TclError: + pass label = Label(tw, text=self.text, justify=LEFT, background="#ffffe0", relief=SOLID, borderwidth=1, From noreply@sourceforge.net Mon Sep 23 02:05:33 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 22 Sep 2002 18:05:33 -0700 Subject: [Idle-dev] [ idlefork-Patches-456006 ] open multiple modules at once Message-ID: Patches item #456006, was opened at 2001-08-27 23:11 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=309579&aid=456006&group_id=9579 Category: None Group: None Status: Open Resolution: Postponed Priority: 3 Submitted By: Stephen M. Gava (elguavas) >Assigned to: Nobody/Anonymous (nobody) Summary: open multiple modules at once Initial Comment: Every time I open a project, I open a lot of modules, and this was usually done by double-clicking each module in import myModule1, myModule2, myModule3, myModule4, myModule5, myModule6 and pressing Alt-M to open it. Now I patched EditorWindow.py to extend the ability of open_module to open a list of modules (and ignore the import keyword), so that one can select the whole line and open all modules with one Alt-M. Below is the changed method open_module in EditorWindow.py, which can be substituted to the original to obtain the new behaviour. def open_module(self, event=None): # XXX Shouldn't this be in IOBinding or in FileList? try: name = self.text.get("sel.first", "sel.last") except TclError: name = "" else: name = string.strip(name) if not name: name = tkSimpleDialog.askstring("Module", "Enter the name of a Python module\n" "to search on sys.path and open:", parent=self.text) name = string.replace(name, ",", " ") name = string.replace(name, ";", " ") nameList = string.split(name) # XXX Ought to support package syntax # XXX Ought to insert current file's directory in front of path for name in nameList: if name in ["", "import"]: continue try: (f, file, (suffix, mode, type)) = imp.find_module(name) except (NameError, ImportError), msg: tkMessageBox.showerror("Import error", str(msg), parent=self.text) return if type != imp.PY_SOURCE: tkMessageBox.showerror("Unsupported type", "%s is not a source module" % name, parent=self.text) return if f: f.close() if self.flist: self.flist.open(file) else: self.io.loadfile(file) Daniel Haertle ------------------------------------------------------------------------ Daniel Haertle haertle@iqe.phys.ethz.ch _________________ ___ http://www.nlo.ethz.ch / ____/_ __/ /_/ / ETH Hoenggerberg - Nonlinear Optics Laboratory / __/_ / / / __ / Institute of Quantum Electronics, HPF E18 /______/ /__/ /__/ /__/ 8093 Zuerich - Switzerland Tel +41 1 63 32338 Fax +41 1 63 31056 ------------------------------------------------------------------------ ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2002-09-22 19:54 Message: Logged In: YES user_id=149084 Per GvR Python style guide, PEP 8, multiple module names on one line are discouraged. The sylistically allowable exceptions are rather minor. Downgrade priority pending further discussion whether this is worthwhile. ---------------------------------------------------------------------- Comment By: Stephen M. Gava (elguavas) Date: 2001-10-07 21:59 Message: Logged In: YES user_id=75867 I like this idea in principle. I float implementation detail ideas on idle-dev when I get the chance to eventually come back to this in earnest. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=309579&aid=456006&group_id=9579 From noreply@sourceforge.net Mon Sep 23 02:10:31 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 22 Sep 2002 18:10:31 -0700 Subject: [Idle-dev] [ idlefork-Patches-451442 ] Adds refresh button to class browser Message-ID: Patches item #451442, was opened at 2001-08-15 22:59 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=309579&aid=451442&group_id=9579 Category: None Group: None Status: Open Resolution: Later >Priority: 3 Submitted By: Chui Tey (teyc) >Assigned to: Nobody/Anonymous (nobody) Summary: Adds refresh button to class browser Initial Comment: This patch does two things: a) ClassBrowser has a refresh button b) ClassBrowser 'docks' itself to the right hand side of the source window. ---------------------------------------------------------------------- Comment By: Stephen M. Gava (elguavas) Date: 2001-10-07 21:57 Message: Logged In: YES user_id=75867 interesting. will look at this in detail after new config stuf is in place and working. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=309579&aid=451442&group_id=9579 From tonylownds@users.sourceforge.net Mon Sep 23 02:11:59 2002 From: tonylownds@users.sourceforge.net (Tony Lownds) Date: Sun, 22 Sep 2002 18:11:59 -0700 Subject: [Idle-dev] CVS: idle config-keys.def,1.12,1.13 Message-ID: Update of /cvsroot/idlefork/idle In directory usw-pr-cvs1:/tmp/cvs-serv13153 Modified Files: config-keys.def Log Message: Blank line missing. Index: config-keys.def =================================================================== RCS file: /cvsroot/idlefork/idle/config-keys.def,v retrieving revision 1.12 retrieving revision 1.13 diff -C2 -r1.12 -r1.13 *** config-keys.def 23 Sep 2002 00:57:10 -0000 1.12 --- config-keys.def 23 Sep 2002 01:11:57 -0000 1.13 *************** *** 100,103 **** --- 100,104 ---- toggle-tabs= change-indentwidth= + [IDLE Classic Mac] copy= From tony@lownds.com Mon Sep 23 02:14:28 2002 From: tony@lownds.com (Tony Lownds) Date: Sun, 22 Sep 2002 18:14:28 -0700 Subject: [Idle-dev] CVS: idle config-keys.def,1.11,1.12 In-Reply-To: References: Message-ID: I will be updating this file with the feedback from various kind volunteers, with their reasoning as cvs comments. These keys already include some of the feedback from Russell Owen. -Tony At 5:57 PM -0700 9/22/02, Tony Lownds wrote: >Update of /cvsroot/idlefork/idle >In directory usw-pr-cvs1:/tmp/cvs-serv9963 > >Modified Files: > config-keys.def >Log Message: >Added new standard keybinding set for Macs. > >Index: config-keys.def >=================================================================== >RCS file: /cvsroot/idlefork/idle/config-keys.def,v >retrieving revision 1.11 >retrieving revision 1.12 >diff -C2 -r1.11 -r1.12 >*** config-keys.def 14 Sep 2002 03:18:43 -0000 1.11 >--- config-keys.def 23 Sep 2002 00:57:10 -0000 1.12 >*************** >*** 100,101 **** >--- 100,146 ---- > toggle-tabs= > change-indentwidth= >+ [IDLE Classic Mac] >+ copy= >+ cut= >+ paste= >+ beginning-of-line= >+ center-insert= >+ close-all-windows= >+ close-window= >+ end-of-file= >+ python-docs= >+ python-context-help= >+ history-next= >+ history-previous= >+ interrupt-execution= >+ open-class-browser= >+ open-module= >+ open-new-window= >+ open-window-from-file= >+ plain-newline-and-indent= >+ print-window= >+ redo= >+ remove-selection= >+ save-window-as-file= >+ save-window= >+ save-copy-of-window-as-file= >+ select-all= >+ toggle-auto-coloring= >+ undo= >+ find= >+ find-again= >+ find-in-files= >+ find-selection= >+ replace= >+ goto-line= >+ smart-backspace= >+ newline-and-indent= >+ smart-indent= >+ indent-region= >+ dedent-region= >+ comment-region= >+ uncomment-region= >+ tabify-region= >+ untabify-region= >+ toggle-tabs= >+ change-indentwidth= > > >_______________________________________________ >IDLE-dev mailing list >IDLE-dev@python.org >http://mail.python.org/mailman/listinfo/idle-dev From tony@lownds.com Mon Sep 23 02:25:55 2002 From: tony@lownds.com (Tony Lownds) Date: Sun, 22 Sep 2002 18:25:55 -0700 Subject: [Idle-dev] use_subprocess issues... Message-ID: --============_-1179378133==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" Kurt, the subprocess code has some strange behavior on Mac OS X. I'm working on it, in the meantime, let me know if I shouldn't commit a workaround. The problem is that on Mac OS X os.spawnv([sys.executable, "-c", "command"]) does NOT start a plain vanilla python! Instead the main code (PyShell.py really) is called, and the "-c" "command" arguments are interpreted by PyShell.py The workaround is to make your hardwired setting vary for the Mac OS X platform. Thoughts? -Tony --- PyShell.py 18 Sep 2002 17:07:05 -0000 1.26 +++ PyShell.py 23 Sep 2002 01:12:53 -0000 @@ -28,8 +28,15 @@ import rpc import RemoteDebugger -# XX hardwire this for now, remove later KBK 09Jun02 -use_subprocess = 1 # Set to 1 to spawn subprocess for command execution +# +# use_subprocess - if set, spawn subprocesses for command execution +# +use_subprocess = 1 + +# The subprocess code needs to be handled in this file for Mac OS X - until +# that change is made, don't use the new sub process code. +if sys.platform == 'darwin' and sys.executable.count('.app'): + use_subprocess = 0 # Change warnings module to write to sys.__stderr__ try: --============_-1179378133==_ma============ Content-Type: text/html; charset="us-ascii" use_subprocess issues...
Kurt, the subprocess code has some strange behavior on Mac OS X. I'm working on it, in the meantime, let me know if I shouldn't commit a workaround.

The problem is that on Mac OS X os.spawnv([sys.executable, "-c", "command"]) does NOT start a plain vanilla python! Instead the main code (PyShell.py really) is called, and the "-c" "command" arguments are interpreted by PyShell.py

The workaround is to make your hardwired setting vary for the Mac OS X platform.

Thoughts?

-Tony

--- PyShell.py  18 Sep 2002 17:07:05 -0000      1.26
+++ PyShell.py  23 Sep 2002 01:12:53 -0000
@@ -28,8 +28,15 @@
 import rpc
 import RemoteDebugger
 
-# XX hardwire this for now, remove later  KBK 09Jun02
-use_subprocess = 1 # Set to 1 to spawn subprocess for command execution
+#
+# use_subprocess - if set, spawn subprocesses for command execution
+#
+use_subprocess = 1
+
+# The subprocess code needs to be handled in this file for Mac OS X - until
+# that change is made, don't use the new sub process code.
+if sys.platform == 'darwin' and sys.executable.count('.app'):
+  use_subprocess = 0
 
 # Change warnings module to write to sys.__stderr__
 try:
--============_-1179378133==_ma============-- From noreply@sourceforge.net Mon Sep 23 03:56:26 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Sun, 22 Sep 2002 19:56:26 -0700 Subject: [Idle-dev] [ idlefork-Patches-470637 ] better doc path on windows Message-ID: Patches item #470637, was opened at 2001-10-12 12:21 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=309579&aid=470637&group_id=9579 Category: None Group: None Status: Open Resolution: None >Priority: 7 Submitted By: Bruce Sherwood (bsherwood) Assigned to: Nobody/Anonymous (nobody) Summary: better doc path on windows Initial Comment: In EditorWindow.py, I suggest a better path to the documentation on Windows. The old way is commented out below; it says to start from where EditorWindow.py is located, come up two parent levels, then go down to \Doc\index.html. This works fine as long as idle is in Python21\Tools, but would not work if idle were in some arbitrary location. if sys.platform[:3] == "win": fn = os.path.split(sys.executable)[0] +'\Doc\index.html' ## fn = os.path.dirname(__file__) ## fn = os.path.join(fn, os.pardir, os.pardir, "Doc", "index.html") ## fn = os.path.normpath(fn) ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2002-09-22 21:56 Message: Logged In: YES user_id=149084 Stephen Gava made some improvements in Rev 1.23 which added pythlp.chm support for the win platform. (22Apr2002) PEP 250 standardizes the location of Idle on Windows but the canonical location of the docs requires investigation. Also, EditorWindow does not handle locally installed html docs on other platforms, e.g. Linux. It accesses the mother ship. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=309579&aid=470637&group_id=9579 From kbk@users.sourceforge.net Mon Sep 23 05:10:40 2002 From: kbk@users.sourceforge.net (Kurt B. Kaiser) Date: Sun, 22 Sep 2002 21:10:40 -0700 Subject: [Idle-dev] CVS: idle PyShell.py,1.26,1.27 Message-ID: Update of /cvsroot/idlefork/idle In directory usw-pr-cvs1:/tmp/cvs-serv13953 Modified Files: PyShell.py Log Message: Fix bug I created during merge from Python-idle. Also, decided IDENTCHARS is better as global, after all. Index: PyShell.py =================================================================== RCS file: /cvsroot/idlefork/idle/PyShell.py,v retrieving revision 1.26 retrieving revision 1.27 diff -C2 -r1.26 -r1.27 *** PyShell.py 18 Sep 2002 17:07:05 -0000 1.26 --- PyShell.py 23 Sep 2002 04:10:37 -0000 1.27 *************** *** 29,32 **** --- 29,34 ---- import RemoteDebugger + IDENTCHARS = string.ascii_letters + string.digits + "_" + # XX hardwire this for now, remove later KBK 09Jun02 use_subprocess = 1 # Set to 1 to spawn subprocess for command execution *************** *** 313,318 **** linecache.cache[filename] = len(source)+1, 0, lines, filename return filename - - IDENTCHARS = string.ascii_letters + string.digits + "_" def showsyntaxerror(self, filename=None): --- 315,318 ---- From kbk@shore.net Mon Sep 23 18:33:25 2002 From: kbk@shore.net (Kurt B. Kaiser) Date: 23 Sep 2002 13:33:25 -0400 Subject: [Idle-dev] use_subprocess issues... In-Reply-To: References: Message-ID: Tony Lownds writes: > >How does PyShell get called by os.spawnv()? What is sys.executable on > >your Mac, and what is the test for .app doing? On my Linux system > >it's /usr/local/bin/python and the command (a user defined module) > >gets passed to that executable, which is started as a subprocess > >'execution server' to Idle. > > Applications on OS X are directory trees. On Linux they are files in > ELF format, on OSX they are directories. It's strange. The directory > for an application must have a .app extension. Somewhere inside the > directory is a normal executable file, the icon for the application, > and anything else that a application wants to put in there. IDLE is > installed inside it's own IDLE.app directory. The actual executable is > *named* python on disk, but it does not have the same main() as the > python you use. Instead the main() looks for startup code inside the > IDLE.app directory. > > The test for '.app' is looking for that magic extension. Its a > marker to determine if the user is running on darwin/Aqua (a.k.a Mac > OS X) or darwin/X11 (which does happen). Ah. I didn't know if it was short for .apple or .app :) > BTW, I would like to put that test somewhere in a function - is > there an appropriate module? > IMO a function like that should just be a ModifiedInterpreter class method. Put it close to the point of use. > > sys.executable is something like > '/Applications/Python/IDLE.app/Contents/MacOS/python' > > So: running sys.executable runs the special* python in the IDLE.app > directory. That looks for the __main__.pyc file, which is compiled > from "idle.py" > and idle.py runs PyShell. > > Python's normal option processing never happens! I think this is an > odd situation. It seems to me that sys.executable is coming up with the wrong value. It is supposed to be a string containing the name of the interpreter executable, not Idle. While it may be "python", from a practical point of view it's "idle". Isn't there a way to run Python from the command prompt in OS X? That's the executable that should be called. If sys.executable can't be fixed, then maybe special case the args variable in spawn_subprocess() for OS X and feed it the location of the Python command line interpreter. (See below!) > > The only fix I envision is for PyShell to add a new switch (say, -r) > that runs run.main(), used only on Mac OS X. That is kinda ugly, and > I want to discuss it more before working on it. That's more than kinda ugly. I don't recommend that approach! > > It's possible the applet model should be fixed in python. I believe > only Jack Jansen is qualified to make that determination. He is on > vacation right now. If there is no Python command line interpreter in OS X, then that's a problem that Jack would have to be involved in. There certainly should be one. Regards, KBK From tony@lownds.com Tue Sep 24 19:23:14 2002 From: tony@lownds.com (Tony Lownds) Date: Tue, 24 Sep 2002 11:23:14 -0700 Subject: [Idle-dev] use_subprocess issues... In-Reply-To: References: Message-ID: At 1:33 PM -0400 9/23/02, Kurt B. Kaiser wrote: >Tony Lownds writes: > > >> sys.executable is something like >> '/Applications/Python/IDLE.app/Contents/MacOS/python' >> >> So: running sys.executable runs the special* python in the IDLE.app >> directory. That looks for the __main__.pyc file, which is compiled >> from "idle.py" >> and idle.py runs PyShell. >> >> Python's normal option processing never happens! I think this is an >> odd situation. > >It seems to me that sys.executable is coming up with the wrong value. >It is supposed to be a string containing the name of the interpreter >executable, not Idle. While it may be "python", from a practical >point of view it's "idle". Well, it is an interpreter executable! In fact it actually runs python's Py_Main (I said otherwise earlier). But Py_Main, for OSX, when running inside an applet, does not process command line arguments. >Isn't there a way to run Python from the command prompt in OS X? >That's the executable that should be called. Yes, sys.exec_prefix + 'bin/python' is reliable BUT unfortunately that will not include the magic .app directory in argv[0], so running Tkinter (or any other type of GUI) won't work. But it would work for non-GUI scripts. >If sys.executable can't be fixed, then maybe special case the args >variable in spawn_subprocess() for OS X and feed it the location of >the Python command line interpreter. (See below!) > > > > > The only fix I envision is for PyShell to add a new switch (say, -r) >> that runs run.main(), used only on Mac OS X. That is kinda ugly, and >> I want to discuss it more before working on it. > >That's more than kinda ugly. I don't recommend that approach! I doubt you will find it any less ugly, but: how about special casing the idle.py file (or rather, a Mac OS X specific idle.py equivalent?) Something like: ## check to see if we should load idle.py or run.py ## by looking at sys.argv if we_were_spawned: # Load idlelib/run.py which runs the user's code # or interactive interpreter del sys.argv[...] import run run.main() else: # Load idlelib/idle.py which starts the application. import idle >If there is no Python command line interpreter in OS X, then that's a >problem that Jack would have to be involved in. There certainly >should be one. I wonder if py2exe have the same issues? It stems from running as an applet (python source and interpreter bundled into one file somehow). -Tony From kbk@shore.net Wed Sep 25 17:35:51 2002 From: kbk@shore.net (Kurt B. Kaiser) Date: 25 Sep 2002 12:35:51 -0400 Subject: [Idle-dev] use_subprocess issues... In-Reply-To: References: Message-ID: >Tony Lownds writes: > >[KBK] > >It seems to me that sys.executable is coming up with the wrong value. > >It is supposed to be a string containing the name of the interpreter > >executable, not Idle. While it may be "python", from a practical > >point of view it's "idle". > > Well, it is an interpreter executable! In fact it actually runs > python's Py_Main (I said otherwise earlier). But Py_Main, for OSX, > when running inside an applet, does not process command line > arguments. > > >Isn't there a way to run Python from the command prompt in OS X? > >That's the executable that should be called. > > Yes, sys.exec_prefix + 'bin/python' is reliable BUT unfortunately that > will not include the magic .app directory in argv[0], so running > Tkinter (or any other type of GUI) won't work. But it would work for > non-GUI scripts. I haven't done much with OS X beyond fiddling with its command prompt at the local computer store. But it sure acts like xxxBSD. emacs -nw works fine, for example. I didn't try Python, but IMHO any real Unix should provide the Python interpreter at the command prompt :) Does the Python2.2 that Apple is shipping with Jaguar include Tk? According to Jack's MacPython page, it runs the interpreter from the command line. If I start Python from the Linux command line I can then start the Tkinter test applet: [kbk@float ~/proj/sandbox/idlefork]$ python Python 2.3a0 (#3, May 8 2002, 23:37:01) [GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import Tkinter >>> Tkinter._test >>> Tkinter._test() at which point the tk applet window appears on my desktop. I would think that it would be useful to get that working on Jaguar before proceeding. Regards, KBK From tony@lownds.com Wed Sep 25 18:12:00 2002 From: tony@lownds.com (Tony Lownds) Date: Wed, 25 Sep 2002 10:12:00 -0700 Subject: [Idle-dev] use_subprocess issues... In-Reply-To: References: Message-ID: Hi Kurt, > > >> Yes, sys.exec_prefix + 'bin/python' is reliable BUT unfortunately that >> will not include the magic .app directory in argv[0], so running >> Tkinter (or any other type of GUI) won't work. But it would work for > > non-GUI scripts. It may not be future-proof but there are ways to find the interpreter for the current python release. So, I am pursuing your suggestion of special casing in the spawn_subprocess module. Patch at the end of this file - please let me know if this isn't what you had in mind. I think we can lay this issue to rest! >I haven't done much with OS X beyond fiddling with its command prompt >at the local computer store. But it sure acts like xxxBSD. emacs -nw >works fine, for example. I didn't try Python, but IMHO any real Unix >should provide the Python interpreter at the command prompt :) :) >Does the Python2.2 that Apple is shipping with Jaguar include Tk? Nope >According to Jack's MacPython page, it runs the interpreter from the >command line. The python2.2 that Apple ships is actually included through the Darwin project. That is the Kernel plus BSD but no graphics. So, since the bundled python is built w/o access to any Mac APIs nor X11 (as neither is included in Darwin), Tkinter isn't even possible to include... >If I start Python from the Linux command line I can then start the >Tkinter test applet: > >[kbk@float ~/proj/sandbox/idlefork]$ python >Python 2.3a0 (#3, May 8 2002, 23:37:01) >[GCC egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)] on linux2 >Type "help", "copyright", "credits" or "license" for more information. >>>> import Tkinter >>>> Tkinter._test > > >>> Tkinter._test() > >at which point the tk applet window appears on my desktop. > > >I would think that it would be useful to get that working on Jaguar >before proceeding. tlownds@perhamlite:~% pythonw Python 2.3a0 (#1, Sep 16 2002, 14:01:50) [GCC 3.1 20020420 (prerelease)] on darwin Type "help", "copyright", "credits" or "license" for more information. >>> import Tkinter >>> Tkinter._test() Note the subtle difference.... "pythonw" must be invoked. -Tony +++ PyShell.py 25 Sep 2002 16:53:33 -0000 @@ -160,11 +160,24 @@ rpcclt = None rpcpid = None - def spawn_subprocess(self): - w = ['-W' + s for s in sys.warnoptions] - args = [sys.executable] + w + ["-c", "__import__('run').main()", + def spawn_subprocess(self): + w = ['-W' + s for s in sys.warnoptions] + args = [self.find_executable()] + w + ["-c", "__import__('run').main()", str(self.port)] self.rpcpid = os.spawnv(os.P_NOWAIT, args[0], args) + + def find_executable(self): + if sys.platform == 'darwin' and sys.executable.count('.app'): + # On Mac OS X, avoid calling sys.executable because it ignores + # command-line options (sys.executable is an applet) + # + # Instead, find the executable by looking relative to + # sys.prefix. + executable = os.path.join(sys.prefix, 'Resources', 'Python.app', + 'Contents', 'MacOS', 'python') + return executable + else: + return sys.executable def start_subprocess(self): addr = ("localhost", self.port) From kbk@shore.net Wed Sep 25 20:30:31 2002 From: kbk@shore.net (Kurt B. Kaiser) Date: 25 Sep 2002 15:30:31 -0400 Subject: [Idle-dev] use_subprocess issues... In-Reply-To: References: Message-ID: Tony Lownds writes: > It may not be future-proof but there are ways to find the interpreter > for the current python release. So, I am pursuing your suggestion of > special casing in the spawn_subprocess module. Patch at the end of > this file - please let me know if this isn't what you had in mind. > > I think we can lay this issue to rest! This looks fine and checks out ok on my Linux system. [...] > >Does the Python2.2 that Apple is shipping with Jaguar include Tk? > > Nope Bummer! Well, I suppose you guys are working that issue. Regards, KBK From kbk@users.sourceforge.net Thu Sep 26 23:13:24 2002 From: kbk@users.sourceforge.net (Kurt B. Kaiser) Date: Thu, 26 Sep 2002 15:13:24 -0700 Subject: [Idle-dev] CVS: idle EditorWindow.py,1.31,1.32 config-keys.def,1.13,1.14 configHandler.py,1.24,1.25 Message-ID: Update of /cvsroot/idlefork/idle In directory usw-pr-cvs1:/tmp/cvs-serv13538 Modified Files: EditorWindow.py config-keys.def configHandler.py Log Message: Fix Bug 612886 copy/paste menu items fail (cut vs. Cut etc.) Fix Bug 613006 Ctrl-x Unix Binding Clears Selection (do-nothing does something :) Leave some debugging prints behind, commented out M EditorWindow.py M config-keys.def M configHandler.py Index: EditorWindow.py =================================================================== RCS file: /cvsroot/idlefork/idle/EditorWindow.py,v retrieving revision 1.31 retrieving revision 1.32 diff -C2 -r1.31 -r1.32 *** EditorWindow.py 16 Sep 2002 02:13:15 -0000 1.31 --- EditorWindow.py 26 Sep 2002 22:13:22 -0000 1.32 *************** *** 81,84 **** --- 81,87 ---- self.top.protocol("WM_DELETE_WINDOW", self.close) self.top.bind("<>", self.close_event) + text.bind("<>", self.cut) + text.bind("<>", self.copy) + text.bind("<>", self.paste) text.bind("<>", self.center_insert_event) text.bind("<>", self.help_dialog) *************** *** 312,315 **** --- 315,330 ---- webbrowser.open(url) + def cut(self,event): + self.text.event_generate("<>") + return "break" + + def copy(self,event): + self.text.event_generate("<>") + return "break" + + def paste(self,event): + self.text.event_generate("<>") + return "break" + def select_all(self, event=None): self.text.tag_add("sel", "1.0", "end-1c") *************** *** 744,747 **** --- 759,763 ---- text.keydefs = keydefs for event, keylist in keydefs.items(): + ##print>>sys.__stderr__, "event, list: ", event, keylist if keylist: apply(text.event_add, (event,) + tuple(keylist)) *************** *** 756,759 **** --- 772,776 ---- if keydefs is None: keydefs = self.Bindings.default_keydefs + ##print>>sys.__stderr__, "*keydefs: " , keydefs menudict = self.menudict text = self.text *************** *** 771,774 **** --- 788,792 ---- label = label[1:] underline, label = prepstr(label) + ##print>>sys.__stderr__, "*Event: " , event accelerator = get_accelerator(keydefs, event) def command(text=text, event=event): *************** *** 780,785 **** variable=var) else: menu.add_command(label=label, underline=underline, ! command=command, accelerator=accelerator) def getvar(self, name): --- 798,807 ---- variable=var) else: + ##print>>sys.__stderr__, "label, ul, cmd, accel: ", + ## label, underline, command, + ## accelerator menu.add_command(label=label, underline=underline, ! command=command, ! accelerator=accelerator) def getvar(self, name): Index: config-keys.def =================================================================== RCS file: /cvsroot/idlefork/idle/config-keys.def,v retrieving revision 1.13 retrieving revision 1.14 diff -C2 -r1.13 -r1.14 *** config-keys.def 23 Sep 2002 01:11:57 -0000 1.13 --- config-keys.def 26 Sep 2002 22:13:22 -0000 1.14 *************** *** 16,19 **** --- 16,20 ---- close-all-windows= close-window= + do-nothing= end-of-file= python-docs= *************** *** 109,112 **** --- 110,114 ---- close-all-windows= close-window= + do-nothing= end-of-file= python-docs= Index: configHandler.py =================================================================== RCS file: /cvsroot/idlefork/idle/configHandler.py,v retrieving revision 1.24 retrieving revision 1.25 diff -C2 -r1.24 -r1.25 *** configHandler.py 14 Sep 2002 03:17:01 -0000 1.24 --- configHandler.py 26 Sep 2002 22:13:22 -0000 1.25 *************** *** 497,500 **** --- 497,501 ---- '<>': [''], '<>': [''], + '<>': [''], '<>': [''], '<>': [''], From noreply@sourceforge.net Thu Sep 26 23:29:14 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 26 Sep 2002 15:29:14 -0700 Subject: [Idle-dev] [ idlefork-Bugs-612886 ] Cut/Copy/Paste Menu Items Fail Message-ID: Bugs item #612886, was opened at 2002-09-22 12:44 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=612886&group_id=9579 Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 8 Submitted By: Hernan Martinez Foffani (hfoffani) >Assigned to: Kurt B. Kaiser (kbk) >Summary: Cut/Copy/Paste Menu Items Fail Initial Comment: The Edit/Cut, Edit/Copy Edit/Paste menu items are not working. Neither are the shortcuts keys unless they are the same as the OS default. Windows 2K Python 2.2.1 IDLEfork from CVS Sept 19 ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2002-09-26 17:29 Message: Logged In: YES user_id=149084 A problem with capitalization. However, to avoid future user confusion, make a more substantial fix which allows <> etc. to remain lower case Removing _some_ Tk defaults may be addressed later. Not high priority though. The BicycleRepairman/Extension issue is different and should be a separate bug. EditorWindow.py Rev 1.32 ---------------------------------------------------------------------- Comment By: Josh Robb (josh_robb) Date: 2002-09-22 19:39 Message: Logged In: YES user_id=614376 I have noticed that BicycleRepairMan_Idle.py is not working with CVS idle. The extension loads but menu items do not work. Also my own idle extensions do not have their event's fire (as defined in config-extensions.def) unless they also have keybindings defined. I have been meaning to look at this but have enough other things right now. ---------------------------------------------------------------------- Comment By: Kurt B. Kaiser (kbk) Date: 2002-09-22 19:23 Message: Logged In: YES user_id=149084 Confirmed with Linux/Gnome ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=612886&group_id=9579 From noreply@sourceforge.net Fri Sep 27 00:12:53 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 26 Sep 2002 16:12:53 -0700 Subject: [Idle-dev] [ idlefork-Bugs-613006 ] Ctrl-x Unix Binding Clears Selection Message-ID: Bugs item #613006, was opened at 2002-09-22 19:38 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=613006&group_id=9579 Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Kurt B. Kaiser (kbk) >Assigned to: Kurt B. Kaiser (kbk) Summary: Ctrl-x Unix Binding Clears Selection Initial Comment: Example: I wish to open the module PyShell. I have a module open in an edit window and I highlight PyShell in "import PyShell" When I press Ctrl-x (to be followed by Ctrl-m) the highlighted text is erased. (Undo will restore it.) Ctrl-x works correctly in Python-idle. Linux/Gnome. CVS MAIN as of today. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2002-09-26 18:12 Message: Logged In: YES user_id=149084 config-keys.def,1.13,1.14 configHandler.py,1.24,1.25 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=109579&aid=613006&group_id=9579 From kbk@users.sourceforge.net Fri Sep 27 01:34:33 2002 From: kbk@users.sourceforge.net (Kurt B. Kaiser) Date: Thu, 26 Sep 2002 17:34:33 -0700 Subject: [Idle-dev] CVS: idle OutputWindow.py,1.6,1.7 Message-ID: Update of /cvsroot/idlefork/idle In directory usw-pr-cvs1:/tmp/cvs-serv14574 Modified Files: OutputWindow.py Log Message: Revert Rev 1.6 "Merge Py Idle changes: Rev 1.7 [Python-idle] loewis Convert characters from the locale's encoding on output. Reject characters outside the locale's encoding on input." Not compatible with Python 2.2.1. Forwardport as a SF patch. Index: OutputWindow.py =================================================================== RCS file: /cvsroot/idlefork/idle/OutputWindow.py,v retrieving revision 1.6 retrieving revision 1.7 diff -C2 -r1.6 -r1.7 *** OutputWindow.py 17 Sep 2002 03:40:47 -0000 1.6 --- OutputWindow.py 27 Sep 2002 00:34:31 -0000 1.7 *************** *** 3,7 **** import re import tkMessageBox - import IOBinding class OutputWindow(EditorWindow): --- 3,6 ---- *************** *** 36,47 **** def write(self, s, tags=(), mark="insert"): - # Tk assumes that byte strings are Latin-1; - # we assume that they are in the locale's encoding - if isinstance(s, str): - try: - s = unicode(s, IOBinding.encoding) - except UnicodeError: - # some other encoding; let Tcl deal with it - pass self.text.insert(mark, s, tags) self.text.see(mark) --- 35,38 ---- From noreply@sourceforge.net Fri Sep 27 01:41:21 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 26 Sep 2002 17:41:21 -0700 Subject: [Idle-dev] [ idlefork-Patches-615312 ] Forwardport Locale Encoding I/O Patch Message-ID: Patches item #615312, was opened at 2002-09-26 19:41 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=309579&aid=615312&group_id=9579 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Kurt B. Kaiser (kbk) Assigned to: Kurt B. Kaiser (kbk) Summary: Forwardport Locale Encoding I/O Patch Initial Comment: This change is not compatible with Python 2.1.1 Save for Idlefork/Python merge. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=309579&aid=615312&group_id=9579 From noreply@sourceforge.net Fri Sep 27 01:45:52 2002 From: noreply@sourceforge.net (noreply@sourceforge.net) Date: Thu, 26 Sep 2002 17:45:52 -0700 Subject: [Idle-dev] [ idlefork-Patches-615312 ] Forwardport Locale Encoding I/O Patch Message-ID: Patches item #615312, was opened at 2002-09-26 19:41 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=309579&aid=615312&group_id=9579 Category: None Group: None Status: Open >Resolution: Postponed Priority: 5 Submitted By: Kurt B. Kaiser (kbk) Assigned to: Kurt B. Kaiser (kbk) Summary: Forwardport Locale Encoding I/O Patch Initial Comment: This change is not compatible with Python 2.1.1 Save for Idlefork/Python merge. ---------------------------------------------------------------------- >Comment By: Kurt B. Kaiser (kbk) Date: 2002-09-26 19:45 Message: Logged In: YES user_id=149084 Ahhh, 2.2.1 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=309579&aid=615312&group_id=9579 From tonylownds@users.sourceforge.net Sun Sep 29 01:10:18 2002 From: tonylownds@users.sourceforge.net (Tony Lownds) Date: Sat, 28 Sep 2002 17:10:18 -0700 Subject: [Idle-dev] CVS: idle config-keys.def,1.14,1.15 Message-ID: Update of /cvsroot/idlefork/idle In directory usw-pr-cvs1:/tmp/cvs-serv30691 Modified Files: config-keys.def Log Message: Change key binding to avoid conflict. Index: config-keys.def =================================================================== RCS file: /cvsroot/idlefork/idle/config-keys.def,v retrieving revision 1.14 retrieving revision 1.15 diff -C2 -r1.14 -r1.15 *** config-keys.def 26 Sep 2002 22:13:22 -0000 1.14 --- config-keys.def 29 Sep 2002 00:10:15 -0000 1.15 *************** *** 114,119 **** python-docs= python-context-help= ! history-next= ! history-previous= interrupt-execution= open-class-browser= --- 114,119 ---- python-docs= python-context-help= ! history-next= ! history-previous= interrupt-execution= open-class-browser= From tonylownds@users.sourceforge.net Sun Sep 29 01:23:11 2002 From: tonylownds@users.sourceforge.net (Tony Lownds) Date: Sat, 28 Sep 2002 17:23:11 -0700 Subject: [Idle-dev] CVS: idle keybindingDialog.py,1.8,1.9 Message-ID: Update of /cvsroot/idlefork/idle In directory usw-pr-cvs1:/tmp/cvs-serv812 Modified Files: keybindingDialog.py Log Message: Mac users now see correct modifiers in the Key Binding Entry window. Index: keybindingDialog.py =================================================================== RCS file: /cvsroot/idlefork/idle/keybindingDialog.py,v retrieving revision 1.8 retrieving revision 1.9 diff -C2 -r1.8 -r1.9 *** keybindingDialog.py 6 Jun 2002 00:44:16 -0000 1.8 --- keybindingDialog.py 29 Sep 2002 00:23:08 -0000 1.9 *************** *** 27,36 **** self.keyString=StringVar(self) self.keyString.set('') ! self.keyCtrl=StringVar(self) ! self.keyCtrl.set('') ! self.keyAlt=StringVar(self) ! self.keyAlt.set('') ! self.keyShift=StringVar(self) ! self.keyShift.set('') self.CreateWidgets() self.LoadFinalKeyList() --- 27,36 ---- self.keyString=StringVar(self) self.keyString.set('') ! self.SetModifiersForPlatform() ! self.modifier_vars = [] ! for modifier in self.modifiers: ! variable = StringVar(self) ! variable.set('') ! self.modifier_vars.append(variable) self.CreateWidgets() self.LoadFinalKeyList() *************** *** 75,90 **** textvariable=self.keyString,relief=GROOVE,borderwidth=2) labelKeysBasic.pack(ipadx=5,ipady=5,fill=X) ! checkCtrl=Checkbutton(self.frameControlsBasic, command=self.BuildKeyString, ! text='Ctrl',variable=self.keyCtrl,onvalue='Control',offvalue='') ! checkCtrl.grid(row=0,column=0,padx=2,sticky=W) ! checkAlt=Checkbutton(self.frameControlsBasic, ! command=self.BuildKeyString, ! text='Alt',variable=self.keyAlt,onvalue='Alt',offvalue='') ! checkAlt.grid(row=0,column=1,padx=2,sticky=W) ! checkShift=Checkbutton(self.frameControlsBasic, ! command=self.BuildKeyString, ! text='Shift',variable=self.keyShift,onvalue='Shift',offvalue='') ! checkShift.grid(row=0,column=3,padx=2,sticky=W) labelFnAdvice=Label(self.frameControlsBasic,justify=LEFT, text="Select the desired modifier\n"+ --- 75,88 ---- textvariable=self.keyString,relief=GROOVE,borderwidth=2) labelKeysBasic.pack(ipadx=5,ipady=5,fill=X) ! self.modifier_checkbuttons = {} ! column = 0 ! for modifier, variable in zip(self.modifiers, self.modifier_vars): ! label = self.modifier_label.get(modifier, modifier) ! check=Checkbutton(self.frameControlsBasic, command=self.BuildKeyString, ! text=label,variable=variable,onvalue=modifier,offvalue='') ! check.grid(row=0,column=column,padx=2,sticky=W) ! self.modifier_checkbuttons[modifier] = check ! column += 1 labelFnAdvice=Label(self.frameControlsBasic,justify=LEFT, text="Select the desired modifier\n"+ *************** *** 120,123 **** --- 118,136 ---- labelHelpAdvanced.grid(row=0,column=0,sticky=NSEW) + def SetModifiersForPlatform(self): + """Determine list of names of key modifiers for this platform. + + The names are used to build Tk bindings -- it doesn't matter if the + keyboard has these keys, it matters if Tk understands them. The + order is also important: key binding equality depends on it, so + config-keys.def must use the same ordering. + """ + import sys + if sys.platform == 'darwin' and sys.executable.count('.app'): + self.modifiers = ['Shift', 'Control', 'Option', 'Command'] + else: + self.modifiers = ['Control', 'Alt', 'Shift'] + self.modifier_label = {'Control': 'Ctrl'} + def ToggleLevel(self): if self.buttonLevel.cget('text')[:8]=='Advanced': *************** *** 153,172 **** def GetModifiers(self): ! modList=[] ! ctrl=self.keyCtrl.get() ! alt=self.keyAlt.get() ! shift=self.keyShift.get() ! if ctrl: modList.append(ctrl) ! if alt: modList.append(alt) ! if shift: modList.append(shift) ! return modList def ClearKeySeq(self): self.listKeysFinal.select_clear(0,END) self.listKeysFinal.yview(MOVETO, '0.0') ! self.keyCtrl.set('') ! self.keyAlt.set(''), ! self.keyShift.set('') ! self.keyString.set('') def LoadFinalKeyList(self): --- 166,178 ---- def GetModifiers(self): ! modList = [variable.get() for variable in self.modifier_vars] ! return filter(None, modList) def ClearKeySeq(self): self.listKeysFinal.select_clear(0,END) self.listKeysFinal.yview(MOVETO, '0.0') ! for variable in self.modifier_vars: ! variable.set('') ! self.keyString.set('') def LoadFinalKeyList(self): From tonylownds@users.sourceforge.net Sun Sep 29 01:34:13 2002 From: tonylownds@users.sourceforge.net (Tony Lownds) Date: Sat, 28 Sep 2002 17:34:13 -0700 Subject: [Idle-dev] CVS: idle PyShell.py,1.27,1.28 Message-ID: Update of /cvsroot/idlefork/idle In directory usw-pr-cvs1:/tmp/cvs-serv3073 Modified Files: PyShell.py Log Message: Finding a suitable interpreter to spawn needed tweaking on the Mac Index: PyShell.py =================================================================== RCS file: /cvsroot/idlefork/idle/PyShell.py,v retrieving revision 1.27 retrieving revision 1.28 diff -C2 -r1.27 -r1.28 *** PyShell.py 23 Sep 2002 04:10:37 -0000 1.27 --- PyShell.py 29 Sep 2002 00:34:10 -0000 1.28 *************** *** 161,169 **** rpcpid = None ! def spawn_subprocess(self): ! w = ['-W' + s for s in sys.warnoptions] ! args = [sys.executable] + w + ["-c", "__import__('run').main()", ! str(self.port)] self.rpcpid = os.spawnv(os.P_NOWAIT, args[0], args) def start_subprocess(self): --- 161,182 ---- rpcpid = None ! def spawn_subprocess(self): ! w = ['-W' + s for s in sys.warnoptions] ! args = [self.find_executable()] + w \ ! + ["-c", "__import__('run').main()", str(self.port)] self.rpcpid = os.spawnv(os.P_NOWAIT, args[0], args) + + def find_executable(self): + if sys.platform == 'darwin' and sys.executable.count('.app'): + # On Mac OS X, avoid calling sys.executable because it ignores + # command-line options (sys.executable is an applet) + # + # Instead, find the executable by looking relative to + # sys.prefix. + executable = os.path.join(sys.prefix, 'Resources', + 'Python.app', 'Contents', 'MacOS', 'python') + return executable + else: + return sys.executable def start_subprocess(self): From gradha@terra.es Sun Sep 29 10:43:31 2002 From: gradha@terra.es (Grzegorz Adam Hankiewicz) Date: Sun, 29 Sep 2002 11:43:31 +0200 Subject: [Idle-dev] Question about keybindings Message-ID: <20020929094330.GA14020@pedos.es> Hi. I've installed the idle-python2.2 package for debian and started to play with it. What I wanted to do is change the keybindings. Looks like this can't be done on a per user basis, so I went to /usr/lib/idle-python2.2/keydefs.py and changed them to my taste. I guess this is a feature request so that newer versions include a configuration system which won't overwrite my keybindings preferences. From kbk@shore.net Sun Sep 29 16:29:18 2002 From: kbk@shore.net (Kurt B. Kaiser) Date: 29 Sep 2002 11:29:18 -0400 Subject: [Idle-dev] Question about keybindings In-Reply-To: <20020929094330.GA14020@pedos.es> References: <20020929094330.GA14020@pedos.es> Message-ID: Grzegorz Adam Hankiewicz writes: > I guess this is a feature request so that newer versions include a > configuration system which won't overwrite my keybindings > preferences. > Take a look at http://idlefork.sourceforge.net/ This version of Idle has Stephen M. Gava's configuration system and will do what you are looking for. Currently it must be extracted from CVS as there are no packaged files with the config system available. See www.sourceforge.net/cvs/?group_id=9579 for information on anonymous CVS access to the idlefork project. We are planning an alpha file release in the near future and hope to have this new version of Idle ready for inclusion in Python 2.3. KBK From josh_robb@fastmail.fm Mon Sep 30 23:22:46 2002 From: josh_robb@fastmail.fm (Josh Robb) Date: Tue, 1 Oct 2002 00:22:46 +0200 Subject: [Idle-dev] Calltip's patch... Message-ID: <011601c268d0$5dfb6d00$ed1c0b3e@aaa6kypxrpjb4c> Ok, After some unexpected delays... (including a new pc!) Here is an updated version of the diffs that are currently in the tracker for adding Autocompletion to calltips. (i.e. Showing methods/attributes for a object after you press '.'). The patch has been made against tonight's CVS so should apply cleanly. (But it is my first IDLE patch so if it's no good let me know). It has been lightly cleaned up. So is not _identical_ but it _should_ be functionally identical. The reason I have updated this patch was because I was about to implement this feature myself and thought that I should at least look at this implementation before starting from scratch. Should I add this updated version to the patch in the manager? Or should I start re-working it and then present that version? I have several ideas for improvements to this implementation: 1. Auto completion is distinct from Calltips? Should they be independently configurable/separate extensions? 2. The UI is non obvious and could be improved also does not use the config stuff for keybindings. 3. There is common code which should be factored out. (For introspecting the object at the cursor). 4. The code misses many common cases like 'self.', string/list/dict literal's which can/should be caught. I will start on this tonight so this is mainly just a reminder list for me. Constructive input gratefully received. j.