"Alin Moldoveanu" <[EMAIL PROTECTED]> writes: > I subscribe to the following list of IDLE behavior: > - IDLE detects itself running and open another window instead of > another process when started to edit a script > - if that script is already opened, is shouldn't be opened again, > just its window brought to front
I guess you are referring to the situation when you initiate an edit by right clicking on a Python file and letting Windows start up another copy of IDLE via the file association? That seems difficult: how do you (in a cross-platform way) signal the running process to open a new edit window or raise the existing one? I'd use IDLE's file menu to open files if you are going to do any serious editing. Then there will be only one process. Besides, if you right click you are running without the subprocess because of (hopefully) temporary limitations on running multiple copies of IDLE with their subprocesses. If you open files with the file menu, IDLE functions as you suggested. I don't recommend running w/o the subprocess unless you have a specific need, e.g. you are using IDLE to develop IDLE and you don't want to keep reopening your source file. In that case, edit the IDLE source with a copy of IDLE started with the -n switch, and test using the normal IDLE with subprocess. That way, if you blow up IDLE you usually don't have to switch to Notepad or something to get things running again. File / Recent Files is your friend. > - more debugging facilities Yes, but still simple. At the level of pdb. It doesn't seem worthwhile (to me, anyway) to put a lot of effort into a fancy debugger since I really don't find that much use for one in Python. I would like to be able to examine the stack frames, though, and de-cluttering the class browser would be helpful. Also, IDLE's design concept is KISS: the interface should /appear/ minimalistic, not a clone of e.g. Visual Studio. IDLE should be useful for the widest possible range of users: accessible for beginners and more than adequate for experts. That's my goal, at least. Thanks to everyone for the comments. -- KBK _______________________________________________ IDLE-dev mailing list [email protected] http://mail.python.org/mailman/listinfo/idle-dev
