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

[Tim Peters]

[Guido]
> ...
> (I had to write this because Fred already fixed the code. :-( )

Well, I haven't made much trouble for you lately, so I don't apologize
<wink>.  BTW, I have no problem with disallowing has_key(1, 2).

Two comments:

> 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]).

Surprise!  I've discovered several times over the last year that newcomers
to Python often do expect just that.

This baffled me until I figured out that the people who expected this had
years of prior Perl experience, and Perl often (depending on context
<wink/sigh>) treats a comma-separated list of scalars as "a list"; e.g.

    push(@list, 1, 2);

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".

> (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.)

At the risk of stating the obvious, this kind of thing is much easier to
track down with static typing.  Several std library modules have grown
classes with their own "append" methods over the years, and they usually
take more than one argument, which makes this much harder to find via regexp
search than it used to be.

Here are some definite violations in the current CVS snapshot (whittled down
from hundreds that matched a reasonably good regexp):

Lib/asyncore.py:
			l.append (fd, flags)

		tbinfo.append (
			tb.tb_frame.f_code.co_filename,
			tb.tb_frame.f_code.co_name,
			str(tb.tb_lineno)
			)

Lib/cgi.py:
        r.append(name, value)

Demo/sgi/gl/nurbs.py: about two dozen of the form
	ci.append(-2.5,  -3.7,  1.0)

Used to be much worse than this.