[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