Issue 708007: TelnetPopen3, TelnetBase, Expect split (original) (raw)

A reordering / code-split of Telnet in telnetlib.py into Expect (the lowest base class), TelnetBase, Telnet and TelnetPopen4.

Reason: Expect contains all of the read_xxx(), expect(), write() and select() functions (and the interact() and mt_interact())

TelnetPopen4 and Telnet derive from the same TelnetBase class, and there is nothing stopping anyone from writing a TelnetHTTP or TelnetURL class which will all have the same interface: expect() and write() and even interact()!

weird, huh - typing in URLs and getting the content back, interactively :)

these TelnetXXX classes are all incredibly useful for "remote host management" purposes; also the principle of the TelnetHTTP class is very useful for doing automated testing of web sites. send URL, expect text in it before proceeding with next URL (e.g. login, check to see if login failed or succeeded; react accordingly).

finally! i accidentally found this, when looking for my own work for yet another project that requires this split.

comments - several

  1. the patch was relevant in 2001 at the time of creation; it was relevant for python 2.0, 2.1, 2.2, 2.3 2.4 2.5 and is still relevant now.

  2. out of all of the python projects that i've done, some of which were really quite large (for one person), over half of them have required interaction with other programs - complex interaction - that required the telnetpopen class.

calling out to php, calling out to c programs and using python to perform parallelisation of simple scripts onto multiple systems (a simple version of beowulf clustering), calling out to ssh to manage remote servers - the list goes on.

  1. the changes that guido asked me to make, back in 2001, we talked at cross purposes (and i wasn't up to the task of saying so - sorry guido!).

the changes to split along the expectlib and telnetbase classes have nothing to do whatsoever with the telnet "protocol". in fact, the enhancements that i've made totally isolate the telnet protocol itself into the "Telnet" derived class, and it can clearly be seen that absolutely zero changes to the underlying implementation of the telnet "protocol" are touched.

however, guido was asking me, as part of the acceptance of the changes, to perform what he believed would be some "simple" bug-fixes to the actual inner workings of the (original) telnet code, which required detailed knowledge of the telnet protocol which i simply ... did not have. something to do with IAC.

on the basis of this miscommunication, guido's decision (seen in http://bugs.python.org/issue405228) was to close the issue and reject the code.

however - there is absolutely nothing "irrelevant" about the enhancements, and the original reasons for rejection have absolutely nothing to do with the enhancements.

overall, these enhancements should never have been left to rot - there was never any real reason to leave them for so long, unused; the "expect" command - see wikipedia page - has been available since 1995 and the concept is clearly well-understood as being extremely powerful; many many people in the intervening years since 2001 have written expect libraries in python - e.g. http://www.noah.org/wiki/Pexpect

that one library alone - pexpect - would not need to have been written, if this patch had been accepted at the time it was written.