On Tue, 21 Jan 2020 21:09:57 +1100 Steven D'Aprano <st...@pearwood.info> wrote:
> On Mon, Jan 20, 2020 at 09:59:07PM -0600, Karl O. Pinc wrote: > > > It would be nice if the output format for float was documented, to > > the extent this is possible. > > I don't think we should make any promises about the repr() of floats. > We've already changed the format at least twice: > > - once to switch to the shortest unambiguous representation; > - and once to shift to a more consistent output for NANs. > > (NANs on Windows prior to 2.6 used to be displayed as '1.#IND', if I > recall correctly.) > > We may never want to change output format again, but if we document a > certain format that will be read by people as a guarantee, and that > closes the door to any change without a long and tedious deprecation > period. Understood. But you still might want to document, or even define in the language, that you're outputting the shortest unambiguous representation. Or other such broad principals like IEEE 754 representation compatibility. This is a suggestion, I don't want to advocate. > If anyone wants a guaranteed output format for floats, they ought to > use the various string formatting operations, which offer guaranteed > formatting outputs. Or build your own formatter. > > I think that the most we should promise is that (with the exception > of NANs) float -> repr -> float should round-trip with no change in > value. That would be nice, and is the sort of general principal I'm thinking of. Another one might be "a sign is only printed for negative numbers". I guess I will advocate for _some_ specification built into Python's definition. Otherwise everybody should _always_ build their own formatter; lest they wake up one morning and find that int zero prints as "+0". As mentioned, parts of this discussion could also apply to other numeric types. > > I don't really care whether there's documentation for __str__() or > > __repr__() or something else. I'm just thinking that there should > > be some way to guarantee a well defined "useful" float output > > formatting. > > https://docs.python.org/3/library/stdtypes.html#printf-style-string-formatting > > https://docs.python.org/3/library/string.html#format-string-syntax Thanks. For some reason nobody in #python pointed me to the 'g' format type. That resolves my issue. Unfortunately, because 'g' can strip the trailing ".0" floats formatted with it no longer satisfy the float->str->float immutability property. I can always: out = f'{num:g}' print(out if 'e' in out or '.' in out else f'{out}.0') sort of logic. (With handling for INF and NAN.) A cleaner format would be nice but this works. (The #g format leaves multiple trailing zeros, which is too different from the "minimal" form __repr__() produces.) FYI. It wouldn't hurt to have the PyOS_double_to_string() docs https://docs.python.org/3/c-api/conversion.html point out that "format" uses the codes as defined in your formatting links above. Digging around got me to PyOS_double_to_string() whereupon I was left in the dark about the meaning of the "format" codes. Thanks you all for the help. Regards, Karl <k...@karlpinc.com> Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/MP5OKKVGWLCCYJE7EQ2DOPXFHACGTRN4/ Code of Conduct: http://python.org/psf/codeofconduct/
