[Python-Dev] PEP 461 Final?

Ethan Furman ethan at stoneleaf.us
Mon Jan 20 07:15:24 CET 2014


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~


More information about the Python-Dev mailing list