[Python-3000] Format specifier proposal

[Guido van Rossum]

On 8/14/07, Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> Guido van Rossum wrote:
> > Over lunch we discussed putting !coercion first. IMO {foo!r:20} reads
> > more naturally from left to right
>
> It also has the advantage that the common case of
> 'r' with no other specifications is one character
> shorter and looks tidier, i.e. {foo!r} rather than
> {foo:!r}.
>
> But either way, I suspect I'll find it difficult
> to avoid writing it as {foo:r} in the heat of the
> moment.

I guess __format__ implementations should fall back to a default
formatting spec rather than raising an exception when they don't
understand the spec passed to them.

> > On 8/13/07, Talin <talin at acm.org> wrote:
> > > Where 'coercion' can be 'r' (to convert to repr()), 's' (to convert to
> > > string.)
>
> Is there ever a case where you would need to
> convert to a string?

When the default output produced by __format__ is different from that
produced by __str__ or __repr__ (hard to imagine), or when you want to
use a string-specific option to pad or truncate (more likely).

> > > Originally I liked the idea of putting the type letter at the front,
> > > instead of at the back like it is in 2.5. However, when you think about
> > > it, it actually makes sense to have it at the back.
>
> I'm not so sure about that. Since most of the time
> it's going to be used as a discriminator that determines
> how the rest of the format spec is interpreted, it
> could make more sense to have it at the front.

This can be decided on a type-by-type basis (except for numbers, which
should follow the built-in numbers' example).

> The only reason it's at the back in % formats is
> because that's the only way of telling where the
> format spec ends. We don't have that problem here.

But it's still more familiar to read "10.3f" than "f10.3".

> > > 6) Finally, Guido stressed that he wants to make sure that the
> > > implementation supports fields within fields, such as:
> > >
> > >    {0:{1}.{2}}
>
> Is that recursive? In other words, can the
> nested {} contain another full format spec?

We were trying not to open that can of worms. It's probably
unnecessary to support that, but it may be easier to support it than
to forbid it, and I don't see anything wrong with it.

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