Pinging this thread 2 months later with a progress/status update.
To those that have reviewed, commented, helped, or otherwise pushed this
along, which includes (but is not limited to) Richard Oudkerk, eryksun,
Giampaolo Rodola, thank you.
The short version:
As far as I can tell, the patch is
And as I was writing the thank you to folks, I hit send too early. Also
thank you to Victor Stinner, Guido, Terry Reedy, and everyone else on this
thread :)
- Josiah
On Thu, May 29, 2014 at 5:34 PM, Josiah Carlson josiah.carl...@gmail.com
wrote:
Pinging this thread 2 months later with a
I've got a patch with partial tests and documentation that I'm holding off
on upload because I believe there should be a brief discussion.
Long story short, Windows needs a thread to handle writing in a
non-blocking fashion, regardless of the use of asyncio or plain subprocess.
If you'd like to
On 3/28/2014 5:09 PM, Guido van Rossum wrote:
To be clear, the proposal for Idle would be to still use the RPC
protocol, but run it over a pipe instead of a socket, right?
The was and is the current proposal, assuming that it is the easiest
thing to do that would work. While responding to
On 3/28/2014 5:12 PM, Antoine Pitrou wrote:
On Fri, 28 Mar 2014 16:58:25 -0400
Terry Reedy tjre...@udel.edu wrote:
However, the code below creates a subprocess for one command and one
response, which can apparently be done now with subprocess.communicate.
What I and others need is a
On Sat, 29 Mar 2014 04:44:32 -0400
Terry Reedy tjre...@udel.edu wrote:
On 3/28/2014 5:12 PM, Antoine Pitrou wrote:
On Fri, 28 Mar 2014 16:58:25 -0400
Terry Reedy tjre...@udel.edu wrote:
However, the code below creates a subprocess for one command and one
response, which can apparently
On Sat, 29 Mar 2014 16:30:25 +0100, Antoine Pitrou solip...@pitrou.net wrote:
On Sat, 29 Mar 2014 04:44:32 -0400
Terry Reedy tjre...@udel.edu wrote:
On 3/28/2014 5:12 PM, Antoine Pitrou wrote:
On Fri, 28 Mar 2014 16:58:25 -0400
Terry Reedy tjre...@udel.edu wrote:
However, the code
On 3/29/2014 11:30 AM, Antoine Pitrou wrote:
On Sat, 29 Mar 2014 04:44:32 -0400
Terry Reedy tjre...@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
On 28 March 2014 05:09, Josiah Carlson josiah.carl...@gmail.com wrote:
So yeah. Someone want to make a decision? Tell me to write the docs, I will.
Tell me to go take a long walk off a short pier, I'll thank you for your
time and leave you alone.
I had a need for this a few years ago. It's
2014-03-28 2:16 GMT+01:00 Josiah Carlson josiah.carl...@gmail.com:
def do_login(...):
proc = subprocess.Popen(...)
current = proc.recv(timeout=5)
last_line = current.rstrip().rpartition('\n')[-1]
if last_line.endswith('login:'):
proc.send(username)
if
On 28 March 2014 20:20, Victor Stinner victor.stin...@gmail.com wrote:
2014-03-28 2:16 GMT+01:00 Josiah Carlson josiah.carl...@gmail.com:
def do_login(...):
proc = subprocess.Popen(...)
current = proc.recv(timeout=5)
last_line = current.rstrip().rpartition('\n')[-1]
if
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/27/2014 09:16 PM, Josiah Carlson wrote:
But here's the thing: I can build enough using asyncio in 30-40 lines
of Python to offer something like the above API. The problem is that
it really has no natural home. It uses asyncio, so makes no
On Fri, 28 Mar 2014 10:45:01 -0400, Tres Seaver tsea...@palladion.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/27/2014 09:16 PM, Josiah Carlson wrote:
But here's the thing: I can build enough using asyncio in 30-40 lines
of Python to offer something like the above API.
*This* is the type of conversation that I wanted to avoid. But I'll answer
your questions because I used to do exactly the same thing.
On Fri, Mar 28, 2014 at 3:20 AM, Victor Stinner victor.stin...@gmail.comwrote:
2014-03-28 2:16 GMT+01:00 Josiah Carlson josiah.carl...@gmail.com:
def
On Fri, Mar 28, 2014 at 9:45 AM, Josiah Carlson josiah.carl...@gmail.comwrote:
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
On Fri, Mar 28, 2014 at 10:46 AM, Guido van Rossum gu...@python.org wrote:
On Fri, Mar 28, 2014 at 9:45 AM, Josiah Carlson
josiah.carl...@gmail.comwrote:
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
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+.
On Fri, Mar 28, 2014 at 12:42 PM, Terry Reedy tjre...@udel.edu wrote:
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
On 3/28/2014 11:35 AM, Josiah Carlson wrote:
If it were me, I'd define three methods, with longer names to
clarify what they do, e.g.
proc.write_nonblocking(data)
data = proc.read_nonblocking()
data = proc.read_stderr_nonblocking()
Easily doable.
I'd appreciate being
On 3/28/2014 6:20 AM, Victor Stinner wrote:
Full example of asynchronous communication with a subprocess (the
python interactive interpreter) using asyncio high-level API:
Thank you for writing this. As I explained in response to Josiah, Idle
communicates with a python interpreter subprocess
To be clear, the proposal for Idle would be to still use the RPC protocol,
but run it over a pipe instead of a socket, right?
On Fri, Mar 28, 2014 at 1:58 PM, Terry Reedy tjre...@udel.edu wrote:
On 3/28/2014 6:20 AM, Victor Stinner wrote:
Full example of asynchronous communication with a
On Fri, 28 Mar 2014 16:58:25 -0400
Terry Reedy tjre...@udel.edu wrote:
On 3/28/2014 6:20 AM, Victor Stinner wrote:
Full example of asynchronous communication with a subprocess (the
python interactive interpreter) using asyncio high-level API:
Thank you for writing this. As I explained in
Le 28 mars 2014 21:59, Terry Reedy tjre...@udel.edu a écrit :
On 3/28/2014 6:20 AM, Victor Stinner wrote:
Full example of asynchronous communication with a subprocess (the
python interactive interpreter) using asyncio high-level API:
However, the code below creates a subprocess for one
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:
On 28/03/2014 06:35 pm, Josiah Carlson wrote:
If it were me, I'd define three methods, with longer names to
clarify what they do, e.g.
proc.write_nonblocking(data)
data = proc.read_nonblocking()
data = proc.read_stderr_nonblocking()
Easily doable.
To implement
Hopping in to give my take on this, which I've expressed to Antoine
off-list.
When I first built the functionality about 8.5-9 years ago, I personally
just wanted to be able to build something that could replace some of
Expect: http://expect.sourceforge.net/ . The original and perhaps current
API
Hi,
2014-03-27 22:52 GMT+01:00 Josiah Carlson josiah.carl...@gmail.com:
... but I never made an effort to get it practically working
with asyncore - primarily because such would be functionally impossible on
Windows without a lot of work to pull in a chunk of what was pywin32
libraries (at
2014-03-27 22:52 GMT+01:00 Josiah Carlson josiah.carl...@gmail.com:
* Because it is example docs, maybe a multi-week bikeshedding discussion
about API doesn't need to happen (as long as read line, read X bytes,
read what is available, and write this data - all with timeouts - are
shown, people
You don't understand the point because you don't understand the feature
request or PEP. That is probably my fault for not communicating the intent
better in the past. The feature request and PEP were written to offer
something like the below (or at least enough that the below could be built
with
On 3/27/2014 9:16 PM, Josiah Carlson wrote:
You don't understand the point because you don't understand the feature
request or PEP. That is probably my fault for not communicating the
intent better in the past. The feature request and PEP were written to
offer something like the below (or at
By digging into the internals of a subprocess produced by Popen(), you can
write in a blocking manner to the stdin pipe, and read in a blocking manner
from the stdout/stderr pipe(s). For scripting most command-line operations,
the lack of timeouts and the ability to *stop* trying to read is as
Hi,
For your information, asyncio.subprocess.Process is limited. It's not
possible yet to connect pipes between two processes. Something like
cat | wc -l where the cat stdin comes from Python.
It's possible to enhance the API to implement that, but the timeframe
was too short to implement it
On 26 Mar 2014 08:22, Antoine Pitrou solip...@pitrou.net wrote:
Hi,
On core-mentorship someone asked about PEP 3145 - Asynchronous I/O for
subprocess.popen. I answered that asyncio now has subprocess support
(including non-blocking I/O on the three standard stream pipes), so
it's not
That would be a rather strong unilateral decision. Why don't you ask the
authors? In theory the PEP's proposals could serve in situations where
asyncio isn't appropriate, and asyncio's subprocess I/O isn't the smoothest
API imaginable. (In practice I'm not sure if the PEP would have been
written
On Tue, 25 Mar 2014 16:14:04 -0700
Guido van Rossum gu...@python.org wrote:
That would be a rather strong unilateral decision. Why don't you ask the
authors? In theory the PEP's proposals could serve in situations where
asyncio isn't appropriate, and asyncio's subprocess I/O isn't the smoothest
35 matches
Mail list logo
