This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author lkcl
Recipients christian.heimes, lkcl
Date 2008-05-13.18:02:35
SpamBayes Score 0.005625494
Marked as misclassified No
Message-id <1210701768.27.0.276038447181.issue708007@psf.upfronthosting.co.za>
In-reply-to
Content
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
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.
History
Date User Action Args
2008-05-13 18:02:50lkclsetspambayes_score: 0.00562549 -> 0.005625494
recipients: + lkcl, christian.heimes
2008-05-13 18:02:48lkclsetspambayes_score: 0.00562549 -> 0.00562549
messageid: <1210701768.27.0.276038447181.issue708007@psf.upfronthosting.co.za>
2008-05-13 18:02:46lkcllinkissue708007 messages
2008-05-13 18:02:42lkclcreate