[Patches] [ python-Patches-1520081 ] telnetlib.py change to ease option handling.

SourceForge.net noreply at sourceforge.net
Sun Mar 11 00:13:01 CET 2007


Patches item #1520081, was opened at 2006-07-10 18:48
Message generated for change (Comment added) made by ernestjwtk
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1520081&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Library (Lib)
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Ernest ter Kuile (ernestjwtk)
Assigned to: Nobody/Anonymous (nobody)
Summary: telnetlib.py change to ease option handling.

Initial Comment:
Telnetlib.py has no automatic telnet option handling
mechanism except for the possibility to register a
callback function. If set, the callback is used for
each option as they arrive. If not set, options are
negated.

Using this mechanisme is not elegant when extending the
telnet class in a OO way, and there is currently no
other way to handle this data. 

This patch adds to the callback mechanisme by also
calling an internal function handle_option(), which by
default doesn't do much. This function could then do
something usefull when extending the telnet class.

For backwards compatibility, the current callback
mechanism has not been removed, and, if used, has
priority over the internal function handle_option(),
which is then ignored.

Furthermore to explain the telnet option system, a lot
of comments have been added.



----------------------------------------------------------------------

>Comment By: Ernest ter Kuile (ernestjwtk)
Date: 2007-03-11 00:13

Message:
Logged In: YES 
user_id=1552811
Originator: YES

Wel it does, and this is why I needed it. For me it added two very
important things:
1) it adds the possibility to create a descendant of the telnet class
which can handle the options. Without this, the callback mechanism must
always be handled externaly to the telnet object itself.

2) And since the callback has no concept of self (missing parameters) it
adds the possibility to have more than one instance of the telnet class
which did not need a different version of the callback function each time.
I needed about 6 instances (one for each system I had to reach), so had to
provide 6 _different_ callback functions. (This showed to me that the
callback way of doing was totally broken)

I wanted to (and did) encapsulate the telnet object with something which
itself could provide the knowlege of handling some of the options (in fact
a telnet 3270, which is a special case of the telnet protocol). This would
have been very much harder to do without being able to handle the options
within the objet.

Sorry if I wasn't clear.

Ernest.

----------------------------------------------------------------------

Comment By: Björn Lindqvist (sonderblade)
Date: 2007-03-08 22:48

Message:
Logged In: YES 
user_id=51702
Originator: NO

Since this feature does not add something and is just a new way to do
something that was already possible, maybe it can wait until py3k? I think
having a handle_option() method is clearly a cleaner design than having a
callback. But the advantage is not that great and in py3k you could break
the api and replace the old method with the new one.

----------------------------------------------------------------------

Comment By: Ernest ter Kuile (ernestjwtk)
Date: 2006-07-10 19:09

Message:
Logged In: YES 
user_id=1552811

Changed Category to be Library instead of Modules.
Telnetlib.py is not a module (sorry for confusion) 

Also attached is diff to latest svn telnetlib had some
timeout patch had been applied. (as of 10 july) 

Actually, first look shows no difference between this one
and the previous one, but just to be sure.

Ernest ter Kuile.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=1520081&group_id=5470


More information about the Patches mailing list