[Python-ideas] Added a function to parse str.format() mini-language specifiers

[Eric Smith]

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 
useful.

> 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?