[Python-Dev] __str__ bug?

M.-A. Lemburg mal at egenix.com
Wed Oct 25 11:40:06 CEST 2006

Mike Krell wrote:
>> class S(str):
>>     def __str__(self): return "S.__str__"
>> class U(unicode):
>>     def __str__(self): return "U.__str__"
>> print str(S())
>> print str(U())
>> This script prints:
>> S.__str__
>> U.__str__
> Yes, but "print U()" prints nothing, and the explicit str() should not
> be necessary.

The main difference here is that the string object defines
a tp_print slot, while Unicode doesn't.

As a result, tp_print for the string subtype is called and
this does an extra check for subtypes:

	if (! PyString_CheckExact(op)) {
		int ret;
		/* A str subclass may have its own __str__ method. */
		op = (PyStringObject *) PyObject_Str((PyObject *)op);
		if (op == NULL)
			return -1;
		ret = string_print(op, fp, flags);
		return ret;

For Unicode, the PyObject_Print() API defaults to using
PyObject_Str() which uses the tp_str slot. This maps
directly to a Unicode API that works on the internals
and doesn't apply any extra checks to see if it was called
on a subtype.

Note that this is true for many of the __special__
slot methods you can implement on subtypes of built-in
types - they don't always work as you might expect.

Now in this rather common case, I guess we could add
support to the Unicode object to do extra checks like the
string object does.

Dito for the %-formatting.

Marc-Andre Lemburg

Professional Python Services directly from the Source  (#1, Oct 25 2006)
>>> Python/Zope Consulting and Support ...        http://www.egenix.com/
>>> mxODBC.Zope.Database.Adapter ...             http://zope.egenix.com/
>>> mxODBC, mxDateTime, mxTextTools ...        http://python.egenix.com/

::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ::::

More information about the Python-Dev mailing list