Revised PEP 349: Allow str() to return unicode strings

[wolf]

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