On 01/19/2014 06:56 PM, Stephen J. Turnbull wrote:
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.
I don't think so. I think it's a good argument for the future of Python code. Mind you, I should probably have said %
is primarily for bytes, or even more useful for bytes than for text. The idea being that true text fun stuff requires
format, while bytes can only use % for easy formatting.
Alternative numeric characters [are] 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.
Certainly. And you can't change that either. Oh, wait, you can! Define your
own!
class LocalNum(int):
"displays d, i, and u codes in local language"
def __format__(self, fmt):
# do the fancy stuff so the characters are not ASCII, but whatever
# is local here
Then you could have your text /and/ your numbers be in your own language. But you can't get that using % unless you
always call a custom function and use %s.
(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.)
"'{:d}'.format(True)" is not exceptional, you're right. But "'%d' % True" is, and was singled-out in the unicode
display code to print as '1' and not as 'True'. (Now all int subclasses behave this way (in 3.4 anyways).)
And I think it's the same issue, or at least closely related. If you create a custom number type with the intention of
displaying them in the local lingo, you have to use __format__ because % is hard coded to yield digits that map to ASCII.
These PEPs provide a crutch for such crippled software, allowing them
to hobble into the House of Python 3.
Very picturesque.
That's obvious, so please don't try to obfuscate it; just declare
"consenting adults" and move on.
Lots of features can be abused. That doesn't mean we shouldn't talk about the
intended use cases and encourage those.
--
~Ethan~
_______________________________________________
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
