[Python-3000] PEP 3101 update

Guido van Rossum guido at python.org
Fri Jun 23 19:27:21 CEST 2006

On 6/22/06, Talin <talin at acm.org> wrote:
> Guido van Rossum wrote:
> > To Talin: I'm all for a way to say blah(x, "2.2g") instead of the more
> > verbose "{2.2g}".format(x). In fact it would probably be great if the
> > latter was officially defined as a way to spell the former combined
> > with literal text:
> >
> >   "foo{2.2g}bar{3.3f}spam".format(x, y)
> >
> > is shorter and mor readable than
> >
> >   "foo" + blah(x, "2.2g") + "bar" + blah(y, "3.3f") + "spam"
> >
> > What I object to is only the spelling of blah(x, f) as str(x, f).
> > Perhaps a static string method; but probably better some other
> > built-in or something in a new stdlib module.
> OK, how about this:
>     y.tostr("3.3f")
> Essentially I'm proposing adding an overridable method named 'tostr' (or
> some better name if you can think of one) to class 'object'.
> Advantages over a builtin:
>    -- Doesn't add another global name
>    -- Easily overridable by subclasses (gets rid of the need for a
> __format__ call in my PEP.)
>    -- If we make the conversion argument optional, it could eventually
> replace the magic __str__ method.

I'm not sure that every object should have this method.

Please consider making it just a method in a stdlib module.

Perhaps it could use overloaded functions.

IMO the PEP would do best not to add new builtins or object methods.
(A __format__ method is OK since it just mimics the standard idiom for
providing overridable type-specific operations; but perhaps
overloadable functions are a better alternative.)

--Guido van Rossum (home page: http://www.python.org/~guido/)

More information about the Python-3000 mailing list