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