On 3/28/2014 12:45 PM, Josiah Carlson wrote:
If it makes you feel any better, I spent an hour this morning building a
2-function API for Linux and Windows, both tested, not using ctypes, and
not even using any part of asyncio (the Windows bits are in msvcrt and
_winapi). It works in Python 3.3+. You can see it here:
http://pastebin.com/0LpyQtU5
Thank you. The docs gave me the impression that I could simply write
proc.stdin and read proc.stdout. I failed with even a simple echo server
(on Windows) and your code suggests why. So it does not get lost, I
attached your code to
http://bugs.python.org/issue18823
My interest is with Idle. It originally ran user code in the same
process as the Shell and Editor code. Then Guido added an option to
os.spawn a separate process and communicate through a socket connection
and the option became the default with same process (requested by -N on
the command line) as a backup option. 3.2 switched to using subprocess,
but still with a socket. The problem is that the socket connection
intermittently fails. Firewalls are, or at least used to be one possible
cause, but there are others -- unknown. (While it works, the suggestion
to restart with -N is a mystery to people who have never seen a command
line.) This is one of the biggest sources of complaints about Idle. A
pipe connection method that always worked on Windows, *x, and Mac would
be great in itself and would also allow code simplification by removing
the -n option. (Roger Serwy has suggested the latter as having two modes
makes patching trickier.)
The current socket connection must be non-blocking. Even though the exec
loop part of the Shell window waits for a response after sending a user
statement, everything else is responsive. One can select text in the
window, use the menus, or switch to another window. So Idle definitely
needs non-blocking write and read.
In my ignorance, I have no idea whether the approach in your code or
that in Viktor's code is better. Either way, I will appreciate any help
you give, whether by writing, reviewing, or testing, to make
communication with subprocesses easier and more dependable.
--
Terry Jan Reedy
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
