Guido- Thanks for the pointer. I should just expect it by now, but I still am always surprised by how many times I need to solve some problem and find out the Python community already has a good answer. Last I really looked deeply at Idle's code was back when it still had problems debugging my TK apps due to sharing a process (so a very long time ago, but that limitation drove my move away from it way back then). So, anyway, I'm way behind on what Idle does and how it does it. Looks like it's come a long way and I'll need to study up on it.
As Idle is now, doesn't it still assume you are first starting Idle, and then doing one thing at a time with it (given the one shell)? I want to support a situation where people are running *lots* of small Python apps (perhaps by lots of different authors), and then when you think, "wow, I want a new widget in this running window", then you can fire up some sort of development tool and try putting the widget in there. Of course, there might need a special tool for each widget library to handle resizing etc. and perhaps then afterwards help you modify the source code of a window creation method for that application if you like the results. It might also be a cool way to develop GUIs from scratch too, not exactly in the Squeakish Morphic and Croquet way which is oriented more toward a direct manipulation philosophy of "what you see is what you get" approach, but more in an abstraction embracing way of "what you see is really neat", where you can bring multiple tools using different graphical and textual representations together to focus on a single problem for a moment. So I might use Idle for a debugger, a variant of BoaConstructor as the object inspector, and a variant of SPE as the source code editor, all looking at the same set of applications and coordinating through sockets. All easier said then done, of course, but I hope you would agree that is potentially a more Pythonic "glue" style approach than, say, directly copying Squeak's approach of having everything (tools and apps) run in the same VM (where one careless change to a window opening method or another essential base class method brings the whole development environment to a standstill). I wonder, if I wanted to build on top of Idle's RPC approach, if I might still need to add an intermediate server, so that when any Python application started (including debuggers or object browsers), it would notify this central server it was online? This would be sort of like a Jabber IM server, but for talkative Python applications instead of talkative people. :-) Or perhaps Idle could do this presence server task somehow with minor changes? Then any collection of development tools written using whatever widget sets (and even in whatever language flavors) could be started up, and they could then be pointed at the already running applications of interest (including hung ones) by querying the presence server for what apps were accessible. Perhaps some development apps like debuggers might even automatically focus on apps that had said they were in need of assistance, say if they threw an unhanded exception. I had been thinking of using twisted, but, given your suggestion, I'll look into whether IDLE's abstract rpc "touch" capability could be extended through various ways to cover remotely touching all aspects of any running Python program. Anyway, time to look at the current Idle code, which will probably take me some time. Just to start with, I'll need to figure out what this comment in "rpc.py" means as far as limitations to N<-->N communications: :-) "For security reasons, GvR requested that Idle's Python execution server process connect to the Idle process, which listens for the connection. Since Idle has has only one client per server, this was not a limitation." Security concerns are obviously a big potential drawback to any socket-based approach, but one thing at a time. When/if I ever have something significant to show, I will probably put it here: http://sourceforge.net/projects/patapata (nothing there now though, just got it approved). --Paul Fernhout Guido van Rossum wrote: > Do you realize that IDLE already solves this? It works exactly the way > you say. The mechanism it uses may not be perfect, but it's relatively > independent from IDLE, fairly powerful, and has a number of issues > worked out that would be a pain to rediscover (including support for > Windows as well as Unix). _______________________________________________ IDLE-dev mailing list [email protected] http://mail.python.org/mailman/listinfo/idle-dev
