Movatterモバイル変換
[0]ホーム
[Python-Dev] Revised PEP 349: Allow str() to return unicodestrings
Wolfgang Lippparagate 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 quicklyrealized 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 thefunction definition:: if type(s) is str or type(s) is unicode: ...instead of using ``isinstance()``.Testing for ``type()`` means that instances of derived classes (thatmay or may not change nothing or almost nothing to the underlyingclass) when passed to a function that uses ``str()`` will behave in adifferent way!isn't it more realistic and commonplace to assume that derivatives of aclass do fulfill the requirements of the underlying class? -- which mayturn out to be wrong! but still...the code as it stands means i have to remember that *in this specialcase 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-Devmailing list
[8]ページ先頭