Ethan Furman writes:
Well, that means that this PEP just further strengthens the notion that format is for text (as then a custom numeric type could easily override the display even for :d, :h, etc.) and % is for bytes (where such glyphs are not natively representable anyway).
This argument is specious. Alternative numeric characters just as representable as the ASCII digits are, and in the same way (by defining a bytes <-> str mapping, aka codec). The problem is not that they're non-representable, it's that they're non-ASCII, and the numeric format codes implicitly specify the ASCII numerals when in text as well as when in bytes. There's no technical reason why these features couldn't use EBCDIC or even UTF-16 nowadays. It's purely a convention. But it's a very useful convention, so it's helpful if Python conforms to it. (Note that "{:d}.format(True)" -> '1' works because True *is* an int and so can be d-formatted in principle. It's not an exceptional case. It's a different issue from what you're talking about here.) The problem that EIBTI worries about is that in many places there is a local convention to use not pure ASCII, but a specific ASCII superset. This allows them to take advantage of the common convention of using ASCII for protocol keywords, and at the same time using "legacy" facilities for internal processing of text. Becoming a disadvantage if and when such programs need to communicate with internationalized applications. These PEPs provide a crutch for such crippled software, allowing them to hobble into the House of Python 3. That's obvious, so please don't try to obfuscate it; just declare "consenting adults" and move on.