Removing inconsistency in number formatting.

[slawomirmarczynski]

There is a discrepancy between the default float formatting achieved in different ways, see the source code snippet. It would be appropriate if using :f would by default give the same effect to a float as printing that number without using :f. Currently this is not the case, using :f unexpectedly changes the number of digits printed after the decimal point. Unexpectedly, because it changes one default setting to a completely different default setting.

value = 1.123456789

print(value)                # print result is 1.123456789
print(f"{value}")           # print result is 1.123456789
print(f"{float(value)}")    # print result is 1.123456789
print(f"{value:f}")         # print result is 1.123457
print(f"{float(value):f}")  # print result is 1.123457

# However,
#
# "[...] With no precision given, uses a precision of 6 digits
#  after the decimal point for float [...]"
#
# https://docs.python.org/pl/3/library/string.html#formatstrings

[skirpichev]

It would be appropriate if using :f would by default give the same effect to a float as printing that number without using :f. Currently this is not the case, using :f unexpectedly changes the number of digits printed after the decimal point. Unexpectedly, because it changes one default setting to a completely different default setting.

I don't think it's "unexpected", docs says: Fixed-point notation. For a given precision p, formats the number as a decimal number with exactly p digits following the decimal point. With no precision given, uses a precision of 6 digits after the decimal point for float, and uses a precision large enough to show all coefficient digits for Decimal. If p=0, the decimal point is omitted unless the # option is used.

That's true on your case:

>>> f"{1.123456789:f}"
'1.123457'
>>> len(_.split(".")[1])
6

The default (no formatting type) is well documented too: "For float this is like the 'g' type, except that when fixed-point notation is used to format the result, it always includes at least one digit past the decimal point, and switches to the scientific notation when exp >= p - 1. When the precision is not specified, the latter will be as large as needed to represent the given value faithfully.

For Decimal, this is the same as either 'g' or 'G' depending on the value of context.capitals for the current decimal context.

The overall effect is to match the output of str() as altered by the other format modifiers."

Changing this to f format will be a huge compatibility break. You should open a thread on https://discuss.python.org/c/ideas/6 do discuss such change, if you invent good arguments for this.

[slawomirmarczynski]

I am afraid that to understand what the problem is, intelligence, and even wisdom and good judgment are needed.

The problem is not the inconsistency with the documentation. The problem is that the behavior (confirmed in the documentation) is inconsistent with common sense.

Maintaining two different default settings for floating-point number output is simply nonsensical. Nonsensical because it forces unnecessary memorization of completely redundant details. The idea of Python is simplicity and general convenience of programming. Therefore, the strange behavior of f-string formatting using :f is something that should be changed over time to a uniform approach. Strange because it assumes an arbitrary number of decimal places… someone once entered 6 and it stayed that way. Meanwhile, 8 would be just as good, or maybe even 4? Equally good in this case means “equally bad.” The standard behavior of print(1.123456789) is okay because it is intuitive. What print(f"1.23456789:f") does is hard to consider intuitive, hard to consider consistent with Python’s philosophy.

Simply put, if something is not very good (as is the case with the :f format), it should be improved, not excused by saying it complies with the specification. Improving means correcting the specification and making the implementation work flawlessly according to this new improved specification.

[skirpichev]

The problem is that the behavior (confirmed in the documentation) is inconsistent with common sense.

Maybe, but compatibility break will be too severe to address this via ordinary issue.

Strange because it assumes an arbitrary number of decimal places… someone once entered 6 and it stayed that way.

I would guess it's just for compatibility with the C standard.

C printf has no concept of "no formatting type", that's why Python can take different decisions here.

[slawomirmarczynski]

The C standard is not the Python standard. It should not be taken as justification. Following this false path further, we might start justifying bad practices by saying that someone did something in Algol 68…

Moreover, float numbers in C are so-called single precision numbers, which do not provide sufficient calculation accuracy. A reasonable practice in C has been and still is to use only double precision numbers. Float numbers in Python actually correspond to double precision numbers in C.

Of course, unifying the behavior of f"{x}:f" and str(float(x)) is not a trivial matter. However, it should be considered for Python 4.

[ericvsmith]

@slawomirmarczynski : Unfortunately, this isn't going to change, even if there is a Python 4 (which there won't be). It's not worth breaking all of the code that depends on this.