[Idle-dev] Dealing with a few feature requests

Douglas S. Blank dblank at brynmawr.edu
Fri May 25 21:11:06 CEST 2007


Tal Einat wrote:
 >> Doug wrote:
>> I wonder how hard it would be to make it 2.4/2.5 agnostic? 
> 
> 
> Not hard at all. I actually have a working version of IDLE which is 
> backwards compatible all the way back to Python2.2. But this my 
> development version, with all sorts of new features. It is stable 
> though, I use it daily, and it is in use by about ten of my friends. I'd 
> gladly send you a copy.

Yes, please. Thanks!

> IDLE isn't currently be kept backwards compatible because it is 
> developed as an integral part of CPython. There are a few stdlib modules 
> which are kept backward compatible (email and compiler IIRC), but IDLE 
> is not, unfortunately.
> 
> The changes required are small, and a few #ifdefs (or equivalent) in the 
> code could make backwards compatibility simple. It would be hard to 
> convince the guys who build CPython to adopt this, though.

That's too bad because it makes all of the fixes applicable to many more 
users than those using the latest Python.

Another problem that we wrestle with is handling the current Python 
path. Am I wrong or does one has to go through some work in order to be 
able to "import myfile" where myfile.py might be in an arbitrary place.

One idea: if you open a file in some directory, that directory might be 
appended to the sys.path.

FYI: we had to hack our own IDLE start program because we needed to:

1) Kill other IDLE processes (and their children) because sometimes 
students close IDLE in a harsh manner that leaves the child process 
running, which prevents us from restarting the serial connection to the 
robot.

2) Wrap the PyShell.PyShell.cancel_callback code so that we can send a 
command to stop the robot whenever a CONTROL+C is encountered.

3) Have the option of running some Python code automatically when we 
start (from a file called "mystart.py", if it exists).

I mention these because someone may have a better solution for us, or 
maybe there is something one can put in the idle startup code (or API) 
to make this more general and so we don't have to add our own "idle" 
start program. I've included that program below.

-Doug

> - Tal

#! /usr/bin/env python

from idlelib import PyShell
import sys, os
if os.name in ['nt', 'dos', 'os2'] :
     pid = os.getpid()
     os.system("""taskkill /F /FI "PID ne %d" /IM pythonw.exe /T """ % pid)
     # kill force processes named pythonw.exe
#sys.argv = [sys.argv[0]] + ['-n']
try:
     commands = open("mystart.py", "r").readlines()
except:
     #commands = ["from myro import *\n"] # add commands right here
     # this causes issues with scope
     commands = []
command = ""
for c in commands:
     print ">>>", c,
     command += c
if command != "":
     sys.argv.append("-c")
     sys.argv.append(command)
del command
del commands
del sys
old_cancel_callback = PyShell.PyShell.cancel_callback
def cancel_callback(self, event=None):
     retval = old_cancel_callback(self, event)
     #PyShell.flist.pyshell.interp.runcode(code)
     code = """if "stop" in dir(): stop()"""
     try:
         PyShell.flist.pyshell.interp.rpcclt.asyncqueue("exec", "runcode",
                                                        (code,), {})
     except:
         pass
     return retval
PyShell.PyShell.cancel_callback = cancel_callback
PyShell.main()



More information about the IDLE-dev mailing list