[Python-Dev] String formatting / unicode 2.5 bug?

Nick Coghlan ncoghlan at gmail.com
Wed Aug 23 13:44:44 CEST 2006


John J Lee wrote:
> On Mon, 21 Aug 2006, Nick Coghlan wrote:
> 
>> John J Lee wrote:
>>>> And once the result has been promoted to unicode, __unicode__ is used 
>>>> directly:
>>>>
>>>>>>>  print repr("%s%s" % (a(), a()))
>>>> __str__
>>>> accessing <__main__.a object at 0x00AF66F0>.__unicode__
>>>> __str__
>>>> accessing <__main__.a object at 0x00AF6390>.__unicode__
>>>> __str__
>>>> u'hihi'
>>> I don't understand this part.  Why is __unicode__ called?  Your example 
>>> doesn't appear to show this happening "once [i.e., because?] the result has 
>>> been promoted to unicode" -- if that were true, it would "stand to reason" 
>>> <wink> that the interpreter would then conclude it should call
>>> __unicode__ for all remaining %s, and not bother with __str__.
>> It does try to call unicode directly, but because the example object doesn't 
>> supply __unicode__ it ends up falling back to __str__ instead. The behaviour 
>> is clearer when the example object provides both methods:
> [...]
> 
> If the interpreter is falling back from __unicode__ to __str__ (rather 
> than the other way around, kind-of), that makes much more sense.  I 
> understood that __unicode__ was not provided, of course -- what wasn't 
> clear to me was why the interpreter was calling/accessing those 
> methods/attributes in the sequence it does.  Still not sure I understand 
> what the third __str__ above comes from, but until I've thought it through 
> again, that's my problem.

The sequence is effectively:
x, y = a(), a()
str(x)     # calls x.__str__
unicode(x) # tries x.__unicode__, fails, falls back to x.__str__
unicode(y) # tries y.__unicode__, fails, falls back to y.__str__

The trick in 2.5 is that the '%s' format code, instead of actually calling
str(x), calls x.__str__() directly, and promotes the result to Unicode if
x.__str__() returns a Unicode result.

I'll try to do something to clear up that section of the documentation before
2.5 final.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://www.boredomandlaziness.org


More information about the Python-Dev mailing list