On 3/29/2014 11:30 AM, Antoine Pitrou wrote:
On Sat, 29 Mar 2014 04:44:32 -0400 Terry Reedy <tjreedy@udel.edu> wrote:
On 3/28/2014 5:12 PM, Antoine Pitrou wrote: [for Idle]
Why don't you use multiprocessing or concurrent.futures? They have everything you need for continuous conversation between processes.
I have not used either and no one suggested either before, while Amaury Forgeot d'Arc and Guido suggested subprocess pipes. I added those two ideas to the issue.
Looking at idlelib/rpc.py, it looks largely like an uncommented
Some things have comments or docstrings; I am adding some as I can.
(untested?)
The test of most of Idle is that it works when a person tries to use it, which it most does. I am working on automated tests too.
reimplementation of multiprocessing pipes, with weird architecture choices (RPCServer is actually a client?).
As David said, pre-implementation. It is at least a decade old.
multiprocessing should have everything you need: you can run child processes, communicate with them using Queues, Locks, Conditions, or you can even automate asynchronous execution with a process Pool. Those are cross-platform and use the most appropriate platform-specific primitives (for examples named pipes under Windows). They are also quite well-tested, and duly maintained by Richard :-)
This is not the only thing Idle does that is or should be done elsewhere. If it is done elsewhere in the stdlib (and tested), I am happy to switch. Idle originally created calltips from code objects and docstrings. When inspect.get... did most of the job for functions coded in Python, Idle switched to using that and some calltips code was removed. Once most C coded functions work with inspect.signature (and I do hope the ArgClinic work gets done for 3.5), I will switch and delete more code and some tests. -- Terry Jan Reedy