Re: python strings
Thu, 21 Apr 1994 16:03:59 +0200

> The choice of a fixed size key was intentional. I felt that if the
> key was too long it was probably an error. Now, what exactly is too
> long? I don't know. BTW, I would not object to requiring that a
> key be a NAME or even a string of arbitrary length. The current
> implementation of formatstring and my desire to make minimal changes
> motivated my solution. I am sure that there is a better solution,
> but I would be surprised and impressed if someone could find it
> fewer changes to the existing source.

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 <>
URL: <>