[Python-3000] string.Formatter class

Talin talin at acm.org
Thu Aug 30 09:03:30 CEST 2007


Eric Smith wrote:
> Eric Smith wrote:
>> Jim Jewett wrote:
> 
>>> but you might want to take inspiration from the "tail" of an
>>> elementtree node, and return the field with the literal next to it as
>>> a single object.
>>>
>>>     (literal_text, field_name, format_spec, conversion)
>> I think I like that best.
> 
> I implemented this in r57641.  I think it simplifies things.  At least,
> it's easier to explain.

Actually...I'm in the middle of writing the docs for the reference 
manual, and I'm finding this a little harder to explain. Not *much* 
harder, but a little bit.

I would probably have gone with one of the following:

    # Test for str vs tuple
    literal_text
    (field_name, format_spec, conversion)

    # Test for length of the tuple
    (literal_text)
    (field_name, format_spec, conversion)

    # Test for 'None' format_spec
    (literal_text, None, None)
    (field_name, format_spec, conversion)

However, I'm not adamant about this - it's up to you what you like best, 
I'll come up with a way to explain it. Also I recognize that your method 
is probably more efficient for the nominal use case -- less tuple creation.

Also I wanted to ask: How about making the built-in 'format' function 
have a default value of "" for the second argument? So I can just say:

    format(x)

as a synonym for:

    str(x)

> Due to an optimization dealing with escaped braces, it's possible for
> (literal, None, None, None) to be returned more than once.  I don't
> think that's a problem, as long as it's documented.  If you look at
> string.py's Formatter.vformat, I don't think it complicates the
> implementation at all.

It's also possible for the literal text to be an empty string if you 
have several consecutive format fields - correct?

> Thanks for the suggestion.



More information about the Python-3000 mailing list