Reply to thread

Message: <blockquote data-quote="wolf" data-source="post: 1834199">hi,i guess that anyone reading this pep will agree that*something* must be done to the state of unicode affairsin python. there are zillions of modules out there thathave str() scattered all over the place, and they all*break* on the first mention of düsseldorf...i'm not quite sure myself how to evolve python to makeit grow from unicode-enabled to unicode-perfect, so forme some discussion would be a good thing. only twomicro-remarks to the pep as it stands:1) i dislike the naming of the function ``text()`` --i´ve been using the word 'text' for a long time to mean'some appropriate representation of character data',i.e. mostly something that would pass ::    assert isinstance(x,basestring)i feel this is a fairly common way of defining the term,so to me a function `` text(x)`` should really*   return its argument unaltered if it passes    ``isinstance(x,basestring)``,*   try to return spefically a unicode object (by using    the ``x.__unicode__()`` method, where available)*   or return an 8bit-string (from ``x.__repr__()`` or    ``x.__str__()``)as discussed later on in the pep, it is conceivable toassign the functionality of the ``text()`` function ofthe pep to ``basestring`` -- that would make perfectsense to me (not sure whether that stands scrutiny inthe big picture, tho).2) really minor: somewhere near the beginning it says ::    def text(obj): return '%s' % objand the claim is that this "behaves as desired" exceptfor unicode-issues, which is incorrect. the second linemust read ::    return '%s' % ( obj, )or else it will fail if ``obj`` is a tuple that is notof length one.cheers,_wolf</blockquote>

Verification