A few words about why I support this PEP:
Binary floating-point is weird. It’s machine-friendly, but it’s not particularly human-friendly. So you do your calculations using binary floating-point because that’s what’s efficient for the machine, but when it’s time to present the results of those calculations to a human, the recommended and standard approach is to format your floats, converting them to a form more appropriate for human consumption than a simple
.hex()) would give.
Float formatting can be regarded as a composition of two operations: the first operation potentially changes the value - it conceptually rounds to an internal decimal fixed-point or floating-point format - for example, for “.3f” formatting, we round the input to the nearest representable decimal value in a decimal fixed-point format with 3 digits after the point. For “.5g” formatting, we round to the nearest value representable in a decimal floating-point format with precision 5. Then the second operation chooses how to turn the value into that format into a string, making use of the user’s choices about sign formatting, length padding, whether to display the value in scientific notation or standard fixed-point notation, etc.
The key point for me is that this internal decimal format should be targeting humans, not machines - that’s what formatting is for. The oddity with current formatting is that that internal decimal format includes signed zeros, and that’s peculiar for something that’s aimed at humans rather than machines. The PEP effectively gives an option to target a decimal format that does not have signed zeros, and so is closer to how humans expect to see numbers written. I have encountered complaints in practice about signed zeros in human-facing stuff, though this was for numbers displayed in a GUI rather than in a printed report.
There are other oddities arising from the current formatting: if I format general float values using a format
".1f", I’m effectively binning those values into bins of size
0.1. Except that because of the inclusion of the sign into the result, there are two bins of size
0.05 instead of a single bin of size
So I agree that there’s a real problem to be solved, and that there isn’t an obvious non-fragile way to do it right now, without this PEP or something like it. I don’t love the
z spelling, but I don’t have any better suggestions, and the potential future alignment with C++ is a concrete argument to prefer this spelling over other possibilities.
And yes, other languages don’t seem to support this (yet). But I don’t think that’s for lack of need: with just a few minutes of searching I turned up Stack Overflow questions asking about how to do this in Python, Java, Objective C, and Swift, and I’m sure there are many more examples out there. I don’t see any reason why Python shouldn’t lead the way here.