telnetlib option negotiation callback should be a method

[Steve Reeves]

I wrote:

> I have an application using telnet that requires option subnegotiation
> (specifically, it needs to set a terminal type in the manner of RFC
> 1091).  The standard telnetlib doesn't currently support this.  I
> would like to extend it to do so, but the current design of the option
> negotiation callback makes this difficult.
> 
> Currently, the callback is a function taking a socket as an argument.
> This is adequate for sending data to the server, but not for
> receiving.  It bypasses the Telnet object's internal queue, which may
> already contain the data you're waiting for.  It also requires you to
> reimplement the special processing the protocol requires (undoubling
> IAC characters), and the default negotiation behavior.
> 
> The callback really needs to be a method of the Telnet object, with
> access to the internal queue.  It can implement the default DONT/WONT
> negotiation.  Subclasses can override it to handle the specific
> options they want and forward the rest to the base class.  The
> set_option_negotiation_callback() method would no longer be needed.
> 
> (This question of function vs. method was briefly raised when the
> telnetlib patch was first submitted, <http://www.python.org/sf/416079>,
> but it was left as a function.)
> 
> Opinions?

Ok, I figured out that if you read the suboption parameter data in the
Telnet object's process_rawq method and pass it to the callback function,
you don't necessarily need the callback to be a Telnet method.  However, it
still seems more Pythonic to me to subclass Telnet than to call
set_option_negotiation_callback.

Is anybody out there using the callback as it is currently implemented?
Would anyone care if it were changed to a method?

-- 
Steve Reeves
stever at gate.net