This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author qrczak
Recipients
Date 2006-09-05.22:08:14
SpamBayes Score
Marked as misclassified
Message-id
In-reply-to
Content
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.
History
Date User Action Args
2007-08-23 14:42:30adminlinkissue1551432 messages
2007-08-23 14:42:30admincreate