[Idle-dev] Fwd: Discussion: 2 many IDE's...don´t we want more?!

[Paul D. Fernhout]

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).