When Don Libes first created Expect, he assumed other languages would incorporate bindings relatively quickly. It's a testimony to the package's polish that no substantial efforts were made with other language bindings for many years; it's because his Expect has seemed so perfect, not for any lack of need other languages have.
By 2000, though, unripe Expect-like facilities were available for such languages as Perl and Python. In contrast to the situation for Tk, other languages have not created Expect modules by linking against Don's libraries; instead, they've written "from scratch" in more language-specific fashion.
Python has several Expect initiatives (just as it has a plethora of Web servers, GUI toolkits, and so on). Most advanced appears to be the pure-Python Pexpect [L1 ].
Expect.pm [L2 ]
ruby-expect [L3 ]
How does the programming power of Tcl/Expect compare to that of the Expect modules of other languages? This comparison is far more difficult to explain than might first appear; full understanding involves several subtleties. Here are the highlights:
- Tcl/Expect can do anything the others can do.
- Tcl/Expect is more mature, and, in particular, better-behaved across a range of Unixes.
- Tcl/Expect has exceptionally interesting and powerful channel-processing capabilities, and event-oriented ones in particular, that other Expects don't even attempt. However, only a small minority of Expect programmers ever use these. In fact, many (many) programmers make no more use of Expect than they would of the corresponding telnet module (telnetlib for Python).
Don himself [...] writes on this question [L4 ] in response to "What is it that Expect can do that Pexpect can't".
- That question ("What is it that Expect can do that Pexpect can't") is a bit misleading. It's not that Pexpect can't do things that Expect can; it's that Expect has a lot of extra support to make this kind of programming easier.
As an example, take the interact command which lets the user interact directly with the spawned process. In Pexpect, that's all interact does. (And that may be sufficient for your needs, as you say.) In contrast, Expect's interact has support for detecting patterns during an interact, hooking together multiple spawned processes, etc. Of course, you can do all this by coding it yourself. But your code will be longer - sometimes a lot longer because you'll essentially have to rewrite your own interact, you'll have to debug it, etc. In fact, you may have encountered these situations already but not realized how much simpler the equivalent Expect code would be.
Of course, the extra support may be more than offset by your preference for Python. :-P
[See essay on "Most programmers don't know what Expect can do for them".]
Because of its channel abstraction, Expect can interact with multiple processes quite easily. That has been more cumbersome or even infeasible with Expect extensions available for other languages.
Summary: Expect is generally "better" in the usual ways programmers understand that, compared to Expect-like modules for other languages, in:
- the maturity of its pty management (there's a lot of OS-specific hair here);
- the interact command
- its facility with multiple managed processes or other I/O streams.
- the book Exploring Expect
- the on-line tutorials [...]
- all the examples in the distribution and book