[Python-ideas] Added a function to parse str.format() mini-language specifiers
eric at trueblade.com
Mon Mar 16 21:31:20 CET 2009
Terry Reedy wrote:
> Eric Smith wrote:
>> I'd like to add a function (or method) to parse str.format()'s
>> standard mini-language format specifiers. It's hard to get right, and
>> if PEP 378 is accepted, it gets more complex.
>> So, is such a function desirable, and if so,
> Yes, but I would take it further and and consider the string and
> dict/named-tuple as alternate interfaces to the formatting machinery. So
> I would
If the only use case for this is for non-builtin numeric types, I'd vote
for a named tuple. But since Mark (who's one of the primary users) also
raised the dict issue, I'll give it some thought.
> a) add an inverse function that would take a dict or named tuple and
> produce the field specifier as a string (or raise ValueError). Such a
> string could be embedded into a complete format string. Some people
> might prefer this specification method.
This is a pretty simple transformation. I'm not so sure it's all that
> b> amend built-in format() to take a dict/n-t as the second argument on
> the basis that it is silly to transform the parse result back into a
> string just to be parsed again. This would make repeated calls to
> format faster by eliminating the parsing step.
But format() works for any type, including ones that don't understand
the standard mini-language. What would they do with this info?
More information about the Python-ideas