3 ms·

I thought I'd give a little more information here about why I wrote this library. A good expect library can save a lot of hassle when dealing with a command li

I thought I'd give a little more information here about why I wrote this library. A good expect library can save a lot of hassle when dealing with a command line interface to a system when that's all you have. I've gotten a lot of mileage out of Pexpect, but a constant thorn in my side was the lack of support for using Pexpect on serial devices under Windows, because Pexpect requires a file number to work with. I set out to patch Pexpect with functionality to allow it to work with generic streams (anything that defined a read function), but the code in Pexpect didn't really lend itself well to the updates. About this time I was also dealing with the headaches of string/binary differences between Python 2 and Python 3. I decided that anything I wrote needed to take the same hard-line approach to text vs. binary that Python 3 did. streamexpect is the end result of that. For 95% of cases, it requires only a single line to initialize: with streamexpect.wrap(some_stream) as stream: # do stuff with wrapper Under the hood, there are clear delineations of responsibility that should make it very easy to extend where necessary. Please let me know your questions, comments, and suggestions!

jquast 11y ago
pexpect maintainer here. If this is any kind of criticism on the complexity of pexpect, then you're perfectly correct! Good job, pexpect is unfortunately too old and widely adopted to go changing API for pythonic sake, its freshly due for a rewrite. Trying to mimic a tcl/expect pattern in python made for unpythonic patterns and user confusion. It was far less confusing in 2002 when most python developers had former experience in tcl/expect -- most people these days never heard of it. I feel an expect replacement would best work with the asyncio.StreamReader and asyncio.StreamWriter interfaces, and allow expecting on multiple possible patterns and streams at the same time, using asyncio.wait_for -- which supplies its own timeout functionality, and of course interoperates with the asyncio event loop. Making a python3 asyncio-only library might not be attractive for yesterday's python users, but it might ensure nobody will rewrite it all over again in another 12 years so!
- nastevens 11y ago
  I love the idea of integrating with asyncio, and it definitely makes sense to integrate it now while asyncio functionality is still fresh. I've added a tickler issue to the GitHub repo and you'll hopefully see it in 0.3. And thanks for the good work you do maintaining Pexpect. I wasn't kidding when I said I have gotten a LOT of mileage out of that library!

jquast 11y ago

pexpect maintainer here. If this is any kind of criticism on the complexity of pexpect, then you're perfectly correct! Good job, pexpect is unfortunately too old and widely adopted to go changing API for pythonic sake, its freshly due for a rewrite. Trying to mimic a tcl/expect pattern in python made for unpythonic patterns and user confusion. It was far less confusing in 2002 when most python developers had former experience in tcl/expect -- most people these days never heard of it. I feel an expect replacement would best work with the asyncio.StreamReader and asyncio.StreamWriter interfaces, and allow expecting on multiple possible patterns and streams at the same time, using asyncio.wait_for -- which supplies its own timeout functionality, and of course interoperates with the asyncio event loop. Making a python3 asyncio-only library might not be attractive for yesterday's python users, but it might ensure nobody will rewrite it all over again in another 12 years so!

nastevens 11y ago
I love the idea of integrating with asyncio, and it definitely makes sense to integrate it now while asyncio functionality is still fresh. I've added a tickler issue to the GitHub repo and you'll hopefully see it in 0.3. And thanks for the good work you do maintaining Pexpect. I wasn't kidding when I said I have gotten a LOT of mileage out of that library!