[Python-ideas] One way to do format and print

Nick Coghlan ncoghlan at gmail.com
Tue Sep 8 04:18:40 CEST 2015

On 8 September 2015 at 11:46, Random832 <random832 at fastmail.com> wrote:
> Nick Coghlan <ncoghlan at 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

More information about the Python-ideas mailing list