On 8 September 2015 at 11:46, Random832 wrote:
Nick Coghlan <ncoghlan@gmail.com> writes:
The final reason for introducing a distinct formatting system doesn't
relate to syntax, but rather to semantics. Mod-formatting is defined
around the builtin types, with "__str__" as the catch-all fallback for
interpolating arbitrary objects. PEP 3101 introduced a new *protocol*
method (__format__) that allowed classes more control over how their
instances were formatted, with the typical example being to allow
dates and times to accept strftime formatting strings directly rather
than having to make a separate strftime call prior to formatting.
Python generally follows a philosophy of "constructs with different
semantics should use different syntax"
I guess my problem is that I don't consider the fact that %s forces
something to string, %f to float, etc, to be desired semantics, I
consider it to be a bug that could, and *should*, have been changed by
an alternate-universe PEP.

There's nothing *good* about the fact that '%.20f' % Decimal('0.1')
gives 0.10000000000000000555 instead of 0.10000000000000000000, and that
there are no hooks for Decimal to make it do otherwise.

Ah, but there *is* something good about it: the fact that
percent-formatting is restricted to a constrained set of known types
makes it fundamentally more *predictable* and more *portable* than

The flexibility of str.format is wonderful if you're only needing to
deal with Python code, and Python's type system. It's substantially
less wonderful if you're designing formatting operations that need to
span multiple languages that only have the primitive core defined by C
in common.

These characteristics are what make percent-formatting a more suitable
approach to binary interpolation than the fully flexible formatting
system. Binary interpolation is not only really hard to do right, it's
also really hard to *test* - many of the things that can go wrong are
driven by the specific data values you choose to test with, rather
than being structural errors in the data types you use.

These benefits aren't particularly obvious until you try to live
without them and figure out why you missed them, but we *have* done
that in the 7 years since 2.6 was released, and hence have a good
understanding of why brace-formatting wasn't the wholesale replacement
for percent-formatting that we originally expected it to be.

That said, there *have* been ongoing efforts to improve the numeric
formatting capabilities of printf and related operations in C/C++ that
we haven't been tracking at the Python level. In relation to decimal
support specifically, the C++ write-up at
http://open-std.org/JTC1/SC22/WG21/docs/papers/2014/n3871.html also
links to the C level proposal and the proposed changes to the
interpretation of the floating point codes when working with decimal
data types.

However, as far as I am aware, there isn't anyone specifically
tracking the evolution of printf() formatting codes and reviewing them
for applicability to Python's percent-formatting support - it's done
more in an ad hoc fashion as folks developing in both Python and C/C++
start using a new formatting code on the C/C++ side of things and
request that it also be added to Python.


Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia

Search Discussions

Discussion Posts


Follow ups

Related Discussions



site design / logo © 2018 Grokbase