Bugs item #1551432, was opened at 2006-09-03 05:24 Message generated for change (Comment added) made by bcannon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1551432&group_id=5470
Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. >Category: Python Interpreter Core >Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 9 Submitted By: Marcin 'Qrczak' Kowalczyk (qrczak) >Assigned to: Brett Cannon (bcannon) Summary: __unicode__ breaks for exception class objects Initial Comment: 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'>" ---------------------------------------------------------------------- >Comment By: Brett Cannon (bcannon) Date: 2006-09-09 00:20 Message: Logged In: YES user_id=357491 rev. 51837 and rev. 51838 have the fix in the trunk and 2.5, respectively. ---------------------------------------------------------------------- Comment By: Marcin 'Qrczak' Kowalczyk (qrczak) Date: 2006-09-05 15:08 Message: 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. ---------------------------------------------------------------------- Comment By: Brett Cannon (bcannon) Date: 2006-09-05 11:22 Message: 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()?). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1551432&group_id=5470 _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
