socket.onnect() RE: [Python-bugs-list] <dict>.has_key() allows more than one argument (PR#210)

Joerg-Cyril Hoehle hoehle@tzd.telekom.de
Fri, 24 Mar 2000 16:47:09 +0100 (MET)


Hi,

Guido wrote:
>> was a late addition to Python (it implicitly converts "1, 2" to a tuple),
>> and if you can use
>The form without the extra parentheses passes two arguments to the
>has_key() method.  I'd like to exclude this syntax -- just like
>list.append(1, 2), which also currently means list.append((1, 2)), but
>which should really be disallowed because the user could easily have
>intended list.extend([1, 2]).  (Excluding the latter is not so easy
>because it would break existing sloppy code; for Python 1.6 I think we
>can afford such breakage.)

>was changed, but not all built-ins were fixed.

[I just browsed the site for bugs about asyncore.py and hit this thread...]

Similarly, I'd like to report that in Python 1.4 & 1.5.2,
I noticed that socket.connect() also allows two syntaxes:

socket.connect("localhost",80) and connect(("localhost",80))

Only the latter is currently documented.

The difference cost me a couple of hours of debugging, since asyncore
provides an own connect() with only one argument and I didn't understand
why my connects sometimes worked and sometimes barfed :-(

So please, check the existing code for similar places and either
disallow them all (if I understood the thread correctly, Guido prefers
only a single way, I agree with this), or document both possibilities.

list.append() with multiple arguments as in Lisp would be practical I
bet, but that's a different story (Tim showed in the thread that
asyncore.py uses such a call to append).

Tim wrote:
>acts like Python list.extend([1, 2]).  So that's all the more reason to
>invoke "in the face of ambiguity, refuse the temptation to guess".

Sometimes I believe my english is not good enough to understand Tim's
posts. I'd comment that it's better to avoid the puzzling about the
ambiguity, like about the two different connects() above.  Functions
defined in Python itself wouldn't allow such an ambiguity and require
either one, or two arguments. Please avoid the loss of time to
programmers like me who try to understand what is right when apparently
presented two almost equal interfaces which lead to puzzling bugs.

Regards,
	J"org H"ohle
hoehle@tzd.telekom.de --/ Funktionssicherheit/Reliability
Technologiezentrum T-Nova GmbH/Telekom Research Center