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.
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
