@@ -333,14 +333,17 @@ support could be added later in a backward-compatible way.
333333Removing support for ``parse_float `` in ``tomllib.load[s] ``
334334-----------------------------------------------------------
335335
336- This option is not strictly necessary, since TOML floats are "IEEE 754 binary64
337- values", which is equivalent to a Python ``float `` on most architectures.
338- However, parsing floats differently, such as to ``decimal.Decimal ``, allows
339- users extra precision beyond that promised by the TOML format. In the
340- author of ``tomli ``'s experience, this is particularly useful in scientific and
341- financial applications. This is also useful for other cases that need greater
342- precision, or where end-users include non-developers who may not be aware of
343- the limits of binary64 floats.
336+ This option is not strictly necessary, since TOML floats should be implemented
337+ as "IEEE 754 binary64 values", which is equivalent to a Python ``float `` on most
338+ architectures.
339+
340+ The TOML specification uses the word "SHOULD", however, implying a
341+ recommendation that can be ignored for valid reasons. Parsing floats
342+ differently, such as to ``decimal.Decimal ``, allows users extra precision beyond
343+ that promised by the TOML format. In the author of ``tomli ``'s experience, this
344+ is particularly useful in scientific and financial applications. This is also
345+ useful for other cases that need greater precision, or where end-users include
346+ non-developers who may not be aware of the limits of binary64 floats.
344347
345348There are also niche architectures where the Python ``float `` is not a IEEE 754
346349binary64 value. The ``parse_float `` argument allows users to achieve correct
0 commit comments