On 8 September 2015 at 11:46, Random832
Nick Coghlan
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 brace-formatting. 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. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia