counting occurrences

Alex Martelli aleaxit at
Tue Aug 7 17:45:43 CEST 2001

"Tim Peters" < at> wrote in message
news:mailman.997165211.14595.python-list at
> Fear of that kind of bloat held up the introduction of dict.update() for
> years:  in d.update(e), in case of duplicate keys k, most apps seem to
> e[k] to "win", but some want d[k] to triumph, others would prefer an
> exception get raised, and still others want the new d[k] to be (d[k],
> or [d[k], e[k]] or one of those swapped.  Guido was in a rare mood when he
> said "oh, screw it -- e[k] wins".  You might be able to sell

I guess that must be part of what makes him a great language
designer and me a poor one: faced with such a situation, where
several slight variations make sense, MY instincts would be
to add a second optional flag parameter -- HIS are to block
everything for years and finally choose ONE alternative, no
options allowed.  When looking at it "in the small", my
instincts may make sense to most designers -- but, add half
a dozen option-flags to each of a few hundreds analogous
situation in a language and its libraries, and I suspect my
option-giving instincts would have led to substantial bloat,
while his have kept things reasonably streamlined and
simple, without in the end substantially reducing the power
actually made available to programmers.  Live and learn...!


More information about the Python-list mailing list