On Tue, Aug 30, 2016 at 01:34:27PM -0700, Ken Kundert wrote: > 3. A change to the various string formatting mechanisms to allow outputting > real > numbers with SI scale factors:
This is somewhat similar to a library I wrote for formatting bytes: https://pypi.python.org/pypi/byteformat Given that feature freeze for 3.6 is two weeks way, I don't think that this proposal will appear before 3.7. So I'm interested, but I'm less interested *right now*. So for now I'll limit myself to only a few observations. > >>> print('Speed of light in a vacuum: {:r}m/s.'.format(2.9979e+08)) > Speed of light in a vacuum: 299.79 Mm/s. Do you think that {:r} might be confused with {!r}? What's the mnemonic here? Why "r" for scale factor? > >>> print('Speed of sound in water: %rm/s.' % 1481 > Speed of sound in water: 1.481 km/s. I doubt that you'll get any new % string formatting codes. That's a legacy interface, *not* deprecated but unlikely to get new features added, and it is intended to closely match the C printf codes. A few more questions: (1) Why no support for choosing a particular scale? If this only auto-scales, I'm not interested. (2) Support for full prefix names, so we can format (say) "kilograms" as well as "kg"? (3) Scientific notation and engineering notation? (4) 1e5 versus 1×10^5 notation? (5) Is this really something that format() needs to understand? We can get a *much* richer and more powerful interface by turning it into a generalise numeric pretty-printing library, at the cost of a little less convenience. > 3. Allowing numbers to be formatted with SI prefixes is useful and not > controversial. I wouldn't quite go that far. You made an extremely controversial request (new syntax for scaling prefixes + ignored units) and nearly all the attention was on that. For what its worth, I have no need for a format code which *only* auto-selects the scaling factor. If I don't have at least the option to choose which scaling factor I get, and hence the prefix, this is of little or no use to me, I likely wouldn't use it, and as far as I am concerned the nuisance value of having yet another format string code to learn outweighs the benefit. -- Steve _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
