Issue 11900: 2.7.1 unicode subclasses not calling str() for print statement (original) (raw)
Created on 2011-04-21 18:14 by opstad, last changed 2022-04-11 14:57 by admin. This issue is now closed.
Messages (7)
Author: Dave Opstad (opstad)
Date: 2011-04-21 18:14
Python 2.7.1 doesn't appear to do the usual implicit call to str() for subclasses of unicode. In the following snippet, I would have expected print myTest and print str(myTest) to behave the same:
class Test(unicode): ... def str(self): ... print "In str" ... return (u"*** " + self + u" ").encode('utf-8') ... def unicode(self): ... print "In unicode" ... return u" " + self + u" ***" ... myTest = Test(u"abc") print myTest abc print str(myTest) In str *** abc *** print unicode(myTest) In unicode *** abc ***
Author: R. David Murray (r.david.murray) * 
Date: 2011-04-21 18:28
You subclassed unicode. So print printed the value of your unicode object, which didn't need coercion.
Author: R. David Murray (r.david.murray) *
Date: 2011-04-21 18:37
For the record, this isn't as simple as I made it sound. See, for example, issue 9196.
Author: Dave Opstad (opstad)
Date: 2011-04-21 19:22
I guess I was confused by the inconsistency with Python 3, which does call the str method, even though, again, no coercion is needed:
Python 3.2 (r32:88452, Feb 20 2011, 10:19:59) [GCC 4.0.1 (Apple Inc. build 5493)] on darwin Type "help", "copyright", "credits" or "license" for more information.
class X(str): ... def str(self): ... print("In str") ... return "*** " + self + " ***" ... x = X("abcde") print(x) In str *** abcde *** print(str(x)) In str *** abcde ***
Author: R. David Murray (r.david.murray) *
Date: 2011-04-21 20:22
Well, it's possible I'm wrong and you've found a bug. There are numerous differences between 2 and 3 in both string handling and special method handling, though, so it may be hard to pin down. If you poke around a bit more and still think it is a bug, please reopen.
Author: John Nagle (nagle)
Date: 2011-12-15 19:26
This has nothing to do with Python 3. There's a difference in str handling between Python 2.6 and Python 2.7.2. It's enough to crash BeautifulSoup:
[Thread-8] Unexpected EXCEPTION while processing page "http://www.verisign.com": global name 'str' is not defined [Thread-8] Traceback (most recent call last): ... [Thread-8] File "C:\projects\sitetruth\BeautifulSoup.py", line 646, in prettify [Thread-8] return self.str(encoding, True) [Thread-8] File "C:\projects\sitetruth\BeautifulSoup.py", line 621, in str [Thread-8] contents = self.renderContents(encoding, prettyPrint, indentContents) [Thread-8] File "C:\projects\sitetruth\BeautifulSoup.py", line 656, in renderContents [Thread-8] text = c.str(encoding) [Thread-8] File "C:\projects\sitetruth\BeautifulSoup.py", line 415, in str [Thread-8] return "" % NavigableString.str(self, encoding) [Thread-8] File "C:\projects\sitetruth\BeautifulSoup.py", line 393, in unicode [Thread-8] return str(self, None) [Thread-8] NameError: global name 'str' is not defined
The class method that's failing is simply
class NavigableString(unicode, PageElement): ... def unicode(self): return str(self, None) #### EXCEPTION RAISED HERE ####
def __str__(self, encoding=DEFAULT_OUTPUT_ENCODING):
if encoding:
return self.encode(encoding)
else:
return selfUsing str in the global namespace is probably wrong, and in a later version of BeautifulSoup, that code is changed to
def __unicode__(self):
return str(self).decode(DEFAULT_OUTPUT_ENCODING)which seems to work. However, it is a real change from 2.6 to 2.7 that breaks code.
Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) *
Date: 2011-12-16 08:28
However, it is a real change from 2.6 to 2.7 that breaks code.
John, this issue is not the same as the one above. The difference between Python 2.6 and Python 2.7.2 you mention only applies to % formatting. The change is clearly documented in http://docs.python.org/dev/whatsnew/2.7.html """It’s now possible for a subclass of the built-in unicode type to override the unicode() method."""
This is clearly a bug in the application. There are many ways to break compatibility with bogus code...
History
Date
User
Action
Args
2022-04-11 14:57:16
admin
set
github: 56109
2011-12-16 08:28:02
amaury.forgeotdarc
set
nosy: + amaury.forgeotdarc
messages: +
2011-12-15 19:26:52
nagle
set
nosy: + nagle
messages: +
2011-04-21 20:22:22
r.david.murray
set
messages: +
2011-04-21 19:22:49
opstad
set
messages: +
2011-04-21 18:37:35
r.david.murray
set
messages: +
2011-04-21 18:28:24
r.david.murray
set
status: open -> closed
nosy: + r.david.murray
messages: +
resolution: not a bug
stage: resolved
2011-04-21 18:14:26
opstad
create