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
wrote:
> Pinging this thread 2 months later with a progress/status update.
>
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 re
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 c
On 3/29/2014 11:30 AM, Antoine Pitrou wrote:
On Sat, 29 Mar 2014 04:44:32 -0400
Terry Reedy 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 h
On Sat, 29 Mar 2014 16:30:25 +0100, Antoine Pitrou wrote:
> On Sat, 29 Mar 2014 04:44:32 -0400
> Terry Reedy wrote:
> > On 3/28/2014 5:12 PM, Antoine Pitrou wrote:
> > > On Fri, 28 Mar 2014 16:58:25 -0400
> > > Terry Reedy wrote:
> >
> > >> However, the code below creates a subprocess for one c
On Sat, 29 Mar 2014 04:44:32 -0400
Terry Reedy wrote:
> On 3/28/2014 5:12 PM, Antoine Pitrou wrote:
> > On Fri, 28 Mar 2014 16:58:25 -0400
> > Terry Reedy wrote:
>
> >> However, the code below creates a subprocess for one command and one
> >> response, which can apparently be done now with subpr
On 3/28/2014 5:12 PM, Antoine Pitrou wrote:
On Fri, 28 Mar 2014 16:58:25 -0400
Terry Reedy 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 continuing (non-blocking)
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 Vict
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 write_nonbl
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/0LpyQt
Le 28 mars 2014 21:59, "Terry Reedy" 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 command an
On Fri, 28 Mar 2014 16:58:25 -0400
Terry Reedy 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 response
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 wrote:
> On 3/28/2014 6:20 AM, Victor Stinner wrote:
>
> Full example of asynchronous communication with a subprocess (the
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
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 not
On Fri, Mar 28, 2014 at 12:42 PM, Terry Reedy 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 asyncio (the
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 10:46 AM, Guido van Rossum wrote:
> On Fri, Mar 28, 2014 at 9:45 AM, 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
On Fri, Mar 28, 2014 at 9:45 AM, 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 wor
On Fri, 28 Mar 2014 10:45:01 -0400, Tres Seaver 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. The problem is
*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 wrote:
> 2014-03-28 2:16 GMT+01:00 Josiah Carlson :
> > def do_login(...):
> > proc = subprocess.Popen(...)
>
-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 s
On 28 March 2014 20:20, Victor Stinner wrote:
> 2014-03-28 2:16 GMT+01:00 Josiah Carlson :
>> def do_login(...):
>> proc = subprocess.Popen(...)
>> current = proc.recv(timeout=5)
>> last_line = current.rstrip().rpartition('\n')[-1]
>> if last_line.endswith('login:'):
>> pro
2014-03-28 2:16 GMT+01:00 Josiah Carlson :
> 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 proc.readline(timeout=5).
On 28 March 2014 05:09, Josiah Carlson 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 messy to do on Windows
(c
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
impo
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 leas
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 mi
2014-03-27 22:52 GMT+01:00 Josiah Carlson :
> * 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 can build ev
Hi,
2014-03-27 22:52 GMT+01:00 Josiah Carlson :
> ... 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 the time, Windows was a
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,
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 be
On Tue, 25 Mar 2014 16:14:04 -0700
Guido van Rossum 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
> API imagina
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 wi
On 26 Mar 2014 08:22, "Antoine Pitrou" 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 obvious anythi
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 obvious anything else is needed.
Should we change the PEP's status to Reje
36 matches
Mail list logo
