PEP: Generalised String Coercion

wolf paragate at
Mon Aug 22 11:55:02 CEST 2005


i guess that anyone reading this pep will agree that
*something* must be done to the state of unicode affairs
in python. there are zillions of modules out there that
have 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 make
it grow from unicode-enabled to unicode-perfect, so for
me some discussion would be a good thing. only two
micro-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

*   try to return spefically a unicode object (by using
    the ``x.__unicode__()`` method, where available)

*   or return an 8bit-string (from ``x.__repr__()`` or

as discussed later on in the pep, it is conceivable to
assign the functionality of the ``text()`` function of
the pep to ``basestring`` -- that would make perfect
sense to me (not sure whether that stands scrutiny in
the big picture, tho).

2) really minor: somewhere near the beginning it says ::

    def text(obj): return '%s' % obj

and the claim is that this "behaves as desired" except
for unicode-issues, which is incorrect. the second line
must read ::

    return '%s' % ( obj, )

or else it will fail if ``obj`` is a tuple that is not
of length one.



More information about the Python-list mailing list