On 08/31/2016 01:07 PM, MRAB wrote:
On 2016-08-31 17:19, Guido van Rossum wrote:
On Wed, Aug 31, 2016 at 5:21 AM, Nick Coghlan
wrote: "h" would be a decent choice - it's not only a continuation of the e/f/g pattern, it's also very commonly used as a command line flag for "human-readable output" in system utilities that print numbers.
I like it. So after all the drama we're just talking about adding an 'h' format code that's like 'g' but uses SI scale factors instead of exponents. I guess we need to debate what it should do if the value is way out of range of the SI scale system -- what's it going to do when I pass it 1e50? I propose that it should fall back to 'g' style then, but use "engineering" style where exponents are always a multiple of 3.)
Would you also want h to work with integers?
The existing "alternate form" marker in string formatting could be used to request the use of the base 2 scaling prefixes rather than the base 10 ones: "#h".
Not sure about this one.
'#' already has a meaning for float's 'g' format:
format(1.0, 'g') '1' format(1.0, '#g') '1.00000'
So I think you'd want to pick another type character to mean base 2 scaling, or another character other than #. But it gets cryptic pretty quickly. You could indeed use type == 'b' for floats to mean base 2 scaling, since it has no current meaning, but I'm not sure that's a great idea because 'b' means binary for integers, and if you want to also be able to scale ints (see above), then there's a conflict. Maybe type == 'z'? Or, use something like '@' (or whatever) instead of '#' to mean "the other alternate form", base 2 scaling.
Does the 'type' have to be a single character?
As a practical matter, yes, it should just be a single character. You could make a special case for 'h' and 'hb', but I would not recommend that. Explaining it in the documentation would be confusing. Eric.