On Sun, Jul 25, 2010 at 10:41 AM, Alexander Belopolsky
<alexander.belopol...@gmail.com> wrote:
> On Sun, Jul 25, 2010 at 1:13 PM, Eric Smith <e...@trueblade.com> wrote:
>> On 7/23/10 2:44 AM, Guido van Rossum wrote:
>>>
>>> Indeed, we meant b'...{}...{}...'.format(x, y). The problem is that it
>>> can't invoke x.__format__() or y.__format__() since those will return
>>> text strings instead of bytes. A proposed solution was to try
>>> x.__bformat__() etc. Another proposed solution was to limit x and y to
>>> a small set of common types and hard-code their meanings (e.g.
>>> numbers, bytes, and dates).
>>
>> If there were an __bformat__ method, what would object.__bformat__() return?
>
> Maybe self.__format__(..).encode('ascii')? ...encode('utf-8') is a
> tempting alternative as well.
-1
That would bring back the "it fails for some users but passes for the
developer" problem. (True, if the developer calls .encode('ascii') it
may also break, but then at least it is something the developer chose
to do.)
How hard would it be to recode the sprintf language but with the
locale fixed to "C"? That would always be ASCII. Otherwise,
str(x).encode('ascii') might work, that's like the ISO format with the
'T' replaced by a space. (One issue: it's not fixed-width, since it
shows the microseconds iff they are nonzero. If I had to choose I'd
never show the microseconds.)
--
--Guido van Rossum (python.org/~guido)
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
