[Python-Dev] Status of PEP 3145 - Asynchronous I/O for subprocess.popen
Terry Reedy
tjreedy at udel.edu
Sat Mar 29 21:04:11 CET 2014
On 3/29/2014 11:30 AM, Antoine Pitrou wrote:
> On Sat, 29 Mar 2014 04:44:32 -0400
> Terry Reedy <tjreedy at 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
More information about the Python-Dev
mailing list