You will get the error anyway because the key won't be in the
dictionary. Using newsizedstring() and changing the key type for
get_mapping_item() to object * my version is roughly the same size as
yours (I gained 4 lines by dropping the error :-).
> g> 2) change %s so that if its argument isn't a string it converts to
> g> one using str().
>
> This has also bothered me and I vote for your second option.
>
> In general, I beleive that the language should always make an attempt
> to "do what you ment" rather that triggering an error. The
> formatstring() function is a good example of how not to do this.
> Python provides the mechanism for any object to convert itself to a
> string. So it should be vary rare for a function, any funciton, to
> actually require a string and then complain if it does not get one.
> The same holds for integers and floats. IMHO there are too many
> places in the code that require integers when what is really needed is
> an integer value (getargs for example). There seems to be this
> underlying assumption that if it is not an intobject it can't possibly
> have an integer value. But, Python does of course, provide the hooks
> for any numeric type to present itself as an integer (or float, or
> long, or boolean).
>
> And while I am on the subject (or off the subject as the case may be)
> this same gripe also aplies to sequences and mappings. Not all
> mappings are mappingobjects and both tuples and list are sequences,
> but there are more. Too much code assumes that there is only one
> mapping object or requires either a list or tuple when any sequence
> will do just as well.
>
> Part of the beauty of Python is that it gives its users the ability to
> extend the language by defining new objects that act like existing
> objects but with different semantics or implementations. Code that
> assumes a more specific class of object than is necessary only serves
> to defeat the feature.
I agree in general. My only excuse is that most of the code that
requires a particular type is older than the language features you
mention. There are a few cases where I wouldn't want the automatic
conversion to integers (e.g. floats -- imagine the surprise if
range(10)[3.14] returns 3 instead of raising a TypeError) but that can
be taken care of somehow. Fixes to the code that solve this kind of
problem for a particular module or object type will be gratefully
accepted :-)
--Guido van Rossum, CWI, Amsterdam <Guido.van.Rossum@cwi.nl>
URL: <http://www.cwi.nl/cwi/people/Guido.van.Rossum.html>