Title: TelnetPopen3, TelnetBase, Expect split
Type: enhancement Stage: resolved
Components: Library (Lib) Versions: Python 3.2
Status: closed Resolution: rejected
Dependencies: Superseder:
Assigned To: jackdied Nosy List: BreamoreBoy, christian.heimes, jackdied, lkcl, terry.reedy
Priority: normal Keywords: patch

Created on 2003-03-22 13:34 by lkcl, last changed 2013-03-25 20:34 by terry.reedy. This issue is now closed.

File name Uploaded Description Edit
telnetlib.tgz lkcl, 2003-03-22 13:36 patched and split telnetlib
Messages (7)
msg43113 - (view) Author: Luke Kenneth Casson Leighton (lkcl) Date: 2003-03-22 13:34
A reordering / code-split of Telnet in
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

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
msg59180 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2008-01-03 23:45
Are you still interested in the matter? Please discuss the idea on the
python-dev mailing list and possible create a new patch for Python 2.6.
msg66786 - (view) Author: Luke Kenneth Casson Leighton (lkcl) Date: 2008-05-13 18:02
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.

3) 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 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. 

that one library alone - pexpect - would not need to have been written,
if this patch had been accepted at the time it was written.
msg67548 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2008-05-30 19:07
Since Pexpect is alive and well, doesn't it satisfy your needs? What's
the point of trying to push an alternative implementation that has
lingered for 7 years now?
msg85038 - (view) Author: Jack Diederich (jackdied) * (Python committer) Date: 2009-04-01 16:21
assigning all open telnetlib items to myself
msg114228 - (view) Author: Mark Lawrence (BreamoreBoy) * Date: 2010-08-18 15:06
Is there any interest in seeing the patch updated for py3k?  Any comments from Windows users since Pexpect uses pty which is Linux only?
msg185231 - (view) Author: Terry J. Reedy (terry.reedy) * (Python committer) Date: 2013-03-25 20:34
As per Guido's core-mentorship list post: "Please close"
Date User Action Args
2013-03-25 20:34:19terry.reedysetstatus: open -> closed

nosy: + terry.reedy
messages: + msg185231

resolution: rejected
stage: patch review -> resolved
2010-08-18 16:41:42gvanrossumsetnosy: - gvanrossum
2010-08-18 15:06:05BreamoreBoysetversions: + Python 3.2, - Python 2.6
nosy: + BreamoreBoy

messages: + msg114228

type: enhancement
stage: patch review
2009-04-01 16:21:33jackdiedsetassignee: jackdied

messages: + msg85038
nosy: + jackdied
2008-05-30 19:07:17gvanrossumsetnosy: + gvanrossum
messages: + msg67548
2008-05-30 01:17:12benjamin.petersonsetstatus: closed -> open
resolution: out of date -> (no value)
versions: + Python 2.6, - Python 2.2
2008-05-13 18:02:46lkclsetmessages: + msg66786
2008-02-19 09:32:20christian.heimessetstatus: pending -> closed
2008-01-03 23:45:54christian.heimessetstatus: open -> pending
resolution: out of date
messages: + msg59180
nosy: + christian.heimes
2003-03-22 13:34:34lkclcreate