Issue 1551432: unicode breaks for exception class objects (original) (raw)

PyObject_Unicode and the unicode function stopped working on class objects of subclasses of BaseException in Python 2.5.

unicode(ImportError) Traceback (most recent call last): File "", line 1, in TypeError: descriptor 'unicode' of 'exceptions.BaseException' object needs an argument

It should work analogously to str:

str(ImportError) "<type 'exceptions.ImportError'>"

Logged In: YES user_id=50234

I think the way which is consistent with the current Python implementation is adding the tp_unicode slot.

(Parenthetical remark.

In the binding between Python and my language Kogut I'm exposing various standard APIs between the two languages automatically. And unicode happened to be the only method which I needed to treat specially by tp_getattro. It's the only method I've encountered so far which is called by Python on lots of "ordinary" objects, and which doesn't have a C slot (and the consequence is that my default wrapper shouldn't forward it to the unicode attribute in the other language, but to the appropriate API of the other language which obtains a Unicode rendition).

This was a different issue than the topic of this bug, was solvable, but it was another suggestion that the way of handling unicode is inconsistent with other similar attributes, similar in the sense of the amount of "genericity" and "magicness", and should have a C slot.

The present problem is somewhat dual: now it's me who calls unicode (even if indirectly), and it's Python who provides unicode implementation of its objects.

End of parenthetical remark.)

Anyway, I'm afraid the issue is a symptom of a deeper problem. I was some time ago wondering how does Python distinguish whether x.foo, when x happens to be a class object (or type object), is meant to be an unbound method to be called with instances of that class, or a bound method to operate on the class object itself.

It seems that Python doesn't attempt to use the second interpretation at all. Despite this, various standard operations are dressed in magic methods with names surrounded by double underscores do work for class objects! And while str(x) is the same as x.str() for most objects, it's not true for class objects and type objects: str(x) goes through the C slot while x.str() doesn't work.

The set of methods which have C slots would seem to be just a shortcut for performance, but actually it has a semantic significance. Namely class objects and type objects can have specialized implementations of those methods, but not of ordinary methods.

Fortunately it doesn't matter much in practice because the set of methods supported by class objects is fixed, and it just happens to be the subset of the methods with C slots. Unless some other objects can play the role of classes, and then the problem might reappear; I'm completely ignorant about Python metaclasses.