Raymond Hettinger wrote:
Whoa guys! I think you're treading very far away from and rejecting the whole idea of PEP 3101 which was to be the one ring to bind them all with format(obj, fmt) having just two arguments and doing nothing but passing them on to obj.__fmt__() which would be responsible for parsing a format string.
I completely agree. That's why I said "But this is all orthogonal to the str.format() discussion." I meant "orthogonal" in the "unrelated" sense. I'm completely on board with your PEP 378 as a simple way just to get some simple formatting into numbers.
Also,even if you wanted a flexible clear separate tool just for number formatting, I don't think keyword arguments are the way to go. That is a somewhat heavy approach with limited flexibility. The research in PEP 378 shows that for languages needing fine control and extreme versatility in formatting, some kind of picture string is the way to go. MS Excel is a champ at number/date formatting strings: #,##0 and whatnot. The allow negatives to have placeholders, trailing minus signs, parentheses, etc. Columns can be aligned neating, any type of padding can be used, any type of separator may be specified. The COBOL picture statements also offer flexibility and clarity. Mini-languages of some sort beat the heck out of functions with a zillion optional arguments.
I think picture based is okay and has its place, but a routine like my proposed format_number (which I know is a bad name) is really the heavy lifter for all locale-based number formatting. Decimal shouldn't really have to completely reimplement locale-based formatting, especially when it already exists in the core. I just want to expose it. Eric.