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
--
http://mail.python.org/mailman/listinfo/python-list
