__unicode__ breaks for exception class objects

[Qrczak]

BPO	1551432
Nosy	@brettcannon

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = 'https://github.com/brettcannon'
closed_at = <Date 2008-06-09.15:53:56.524>
created_at = <Date 2006-09-03.12:24:16.000>
labels = ['interpreter-core']
title = '__unicode__ breaks for exception class objects'
updated_at = <Date 2008-06-09.15:53:56.524>
user = 'https://bugs.python.org/qrczak'

bugs.python.org fields:

activity = <Date 2008-06-09.15:53:56.524>
actor = 'davidfraser'
assignee = 'brett.cannon'
closed = True
closed_date = None
closer = None
components = ['Interpreter Core']
creation = <Date 2006-09-03.12:24:16.000>
creator = 'qrczak'
dependencies = []
files = []
hgrepos = []
issue_num = 1551432
keywords = []
message_count = 5.0
messages = ['29747', '29748', '29749', '29750', '67866']
nosy_count = 3.0
nosy_names = ['brett.cannon', 'davidfraser', 'qrczak']
pr_nums = []
priority = 'critical'
resolution = 'fixed'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue1551432'
versions = ['Python 2.5']

[Qrczak]

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 "<stdin>", line 1, in <module>
TypeError: descriptor '__unicode__' of
'exceptions.BaseException' object needs an argument

It should work analogously to str:

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

[brettcannon]

Logged In: YES
user_id=357491

This is because exceptions now define a proper __unicode__()
method in the PyMethodDef array. This is what gets called
and it requires an exception instance. Before it just fell
through to the tp_str slot and that didn't complain.

Unless some knows a better way (short of defining a
tp_unicode slot), the only way to make this work would be to
rip out the __unicode__() method. This would then require
the function in the tp_str slot to have to detect if its
arguments need to be Unicode or not (and I don't know how to
do that off the top of my head; is their a PyUnicode_Check()?).

[Qrczak]

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.

[brettcannon]

Logged In: YES
user_id=357491

rev. 51837 and rev. 51838 have the fix in the trunk and 2.5,
respectively.

[davidfraser]

Note that this causes problems with converting Exceptions to unicode -
see http://bugs.python.org/issue2517