[Python-Dev] Revised PEP 349: Allow str() to return unicode strings (original) (raw)

Wolfgang Lipp paragate at gmx.net
Tue Aug 23 10:46:36 CEST 2005

neil,

i just intended to worry that returning a unicode object from str() would break assumptions about the way that 'type definers' like str(), int(), float() and so on work, but i quickly realized that e.g. int() does return a long where appropriate! since the principle works there one may surmise it will also work for str() in the long run.

one point i don't seem to understand right now is why it says in the function definition::

 if type(s) is str or type(s) is unicode:
     ...

instead of using isinstance().

Testing for type() means that instances of derived classes (that may or may not change nothing or almost nothing to the underlying class) when passed to a function that uses str() will behave in a different way!

isn't it more realistic and commonplace to assume that derivatives of a class do fulfill the requirements of the underlying class? -- which may turn out to be wrong! but still...

the code as it stands means i have to remember that in this special case only (when deriving from unicode), i have to add a __str__() method myself that simply returns self.

then of course, one could change unicode.__str__() to return self, itself, which should work. but then, why so complicated?

i suggest to change said line to::

 if isinstance( s, ( str, unicode ) ):
     ...

any objections?

_wolf

Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

More information about the Python-Dev mailing list