classification
Title: telnetlib.Telnet port number int/str inconsistency
Type: behavior Stage: resolved
Components: Library (Lib) Versions: Python 3.1, Python 3.2, Python 2.7
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: Christian.S..Perone, jackdied, r.david.murray, xuanji
Priority: normal Keywords: patch

Created on 2010-12-13 19:27 by Christian.S..Perone, last changed 2010-12-14 14:37 by r.david.murray. This issue is now closed.

Files
File name Uploaded Description Edit
issue10695.patch xuanji, 2010-12-14 11:47
Messages (8)
msg123894 - (view) Author: Christian S. Perone (Christian.S..Perone) Date: 2010-12-13 19:27
When you use telnetlib with a "str" parameter as Port Number:
tel = telnetlib.Telnet("10.0.2.9", "8123")
tel.read_until("login: ")

It works fine, except if you set the debuglevel:
tel.set_debuglevel(30)

Then the follow exception is thrown:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "c:\python26\lib\telnetlib.py", line 306, in read_until
    self.fill_rawq()
  File "c:\python26\lib\telnetlib.py", line 517, in fill_rawq
    self.msg("recv %r", buf)
  File "c:\python26\lib\telnetlib.py", line 239, in msg
    print 'Telnet(%s,%d):' % (self.host, self.port),
TypeError: %d format: a number is required, not str

I think that the string "Telnet(%s,%d):" on the telnetlib.py should be "Telnet(%s,%s):", since it works fine with a str as Port Number.
msg123930 - (view) Author: Xuanji Li (xuanji) * Date: 2010-12-14 11:47
Alternatively, I think we can do a conversion to int in Telnet.__init__ (see patch)
msg123931 - (view) Author: Christian S. Perone (Christian.S..Perone) Date: 2010-12-14 11:50
I don't know, by doing this on __init__ we can break a lot of legacy codes.
msg123933 - (view) Author: Xuanji Li (xuanji) * Date: 2010-12-14 11:52
Hi, is there any legacy code that would rely on "port" being stored as a string rather than an integer?
msg123934 - (view) Author: Christian S. Perone (Christian.S..Perone) Date: 2010-12-14 11:55
Not from Python itself I think, but external, from users.
msg123935 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2010-12-14 12:51
Yes, for backward compatibility reasons it is better to make the change that fixes the thing that doesn't work and leave the rest alone.  Probably the change wouldn't break *much* existing user code, but why break anything when there doesn't seem to be any particular advantage to doing so?
msg123936 - (view) Author: Christian S. Perone (Christian.S..Perone) Date: 2010-12-14 12:58
Agree.
msg123944 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2010-12-14 14:36
Fixed in py3k in r87230, with test.  Backported to 3.1 in r87231 and 2.7 in r87232.  The 2.7 backport doesn't include the test since the test infrastructure for it doesn't exist in the 2.7 test_telnetlib.
History
Date User Action Args
2010-12-14 14:37:20r.david.murraysetversions: + Python 3.1, Python 2.7, Python 3.2, - Python 2.6
2010-12-14 14:36:43r.david.murraysetstatus: open -> closed
resolution: fixed
messages: + msg123944

stage: resolved
2010-12-14 12:58:21Christian.S..Peronesetmessages: + msg123936
2010-12-14 12:51:24r.david.murraysetnosy: + r.david.murray
messages: + msg123935
2010-12-14 11:55:30Christian.S..Peronesetmessages: + msg123934
2010-12-14 11:52:36xuanjisetmessages: + msg123933
2010-12-14 11:50:26Christian.S..Peronesetmessages: + msg123931
2010-12-14 11:47:21xuanjisetfiles: + issue10695.patch

nosy: + xuanji
messages: + msg123930

keywords: + patch
2010-12-13 20:36:59r.david.murraysetnosy: + jackdied
2010-12-13 19:27:04Christian.S..Peronecreate