[Python-Dev] PEP 3101 Update

Michael Chermside mcherm at mcherm.com
Mon May 8 22:06:41 CEST 2006


I wrote:
> >     - Variable field width specifiers use a nested version of the {}
> >       syntax, allowing the width specifier to be either a positional
> >       or keyword argument:
> >
> >         "{0:{1}.{2}d}".format(a, b, c)
>
> This violates [the rule that '}' must be escaped]

Talin writes:
> What would you suggest? I'd be interested in hearing what kinds of
> ideas people have for fixing these problems.

Honestly? I propose that the PEP not provide any means to pass
format specifiers as arguments. After all, one PEP need not support
everything anyone would ever want to do with string interpolation.
Fixed format attributes are powerful enough for nearly all
applications, and those needing a more powerful tool can either use
multiple interpolation passes (simple and obvious, but a bit ugly)
or define a custom formatting class.

In fact, if _I_ were writing the PEP, I'd probably have opted for
simplicity in a few more areas. For one thing, where you have:

>    string.format() will format each field using the following steps:
>
>     1) See if the value to be formatted has a __format__ method.  If
>        it does, then call it.
>
>     2) Otherwise, check the internal formatter within string.format
>        that contains knowledge of certain builtin types.
>
>     3) Otherwise, call str() or unicode() as appropriate.

I would have left out (2) by adding __format__ methods to those
built-in types just to keep the description (and the implementation)
as simple as possible.

And probably I would have ommitted the whole ability to support custom
formatting classes. Not that they're not a nice idea, but they are a
separate feature which can be built on top of the basic format() method
and I would have tried to take one small step at a time.

But please don't read this as saying I object to the above ideas...
I wouldn't have said anything if you hadn't asked what my approach
would be.

-- Michael Chermside



More information about the Python-Dev mailing list