g> I wrote:
> I DO like Don Beaudry's interpretation of %(<name>)<format> as an
> extension of format strings (except I take objection to copying the
> key to an array of fixed size :-)
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.
g> I still like it, but believe it would be ever so more useful if there
g> were a format specifier that took ANY type of object and converted it
g> to a string using str(). I can think of two options:
g> 1) introduce %p (with the same options as %s) -- the mnemonic of
g> course means "any Python object". (In ANSI C %p means pointer but
g> this doesn't make sense in Python.)
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.
(O.K. I think my spleen is empty now)
--Don
______ ______
\_\_\_\ /#/#/#/
\_\_\_\ ______
\_\_\_V#/#/#/ Donald Beaudry don@vicorp.com
\_\_/#/#/#/ V. I. Corporation uunet!vicorp!don
\_/#/#/#/ 47 Pleasant Street PHONE: (413) 586-4144
V#/#/#/ Northampton, MA 01060 FAX: (413) 586-3805