Eric Smith wrote:
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?
The same thing they would do (whatever that is) if the second argument were instead the equivalent unparsed format-spec string. The easiest implementation of what I am proposing would be for the parse_spec function whose output you propose to expose were to recognize when its input is not a string but previous parse output. Just as iter(iter(ob)) is iter(ob), parse(parse(spec)) should be the same as parse(spec). tjr