On Fri, 07 Jul 2000 07:44:03 -0500, Guido van Rossum <guido@beopen.com> wrote: We debated a ustr function in July. Does anyone have this in hand? I can prepare a patch if necessary.
Toby Dickenson wrote:
I'm just nearing the end of getting Zope to play well with unicode data. Most of the changes involved replacing a call to str, in situations where either a unicode or narrow string would be acceptable.
My best alternative is:
def convert_to_something_stringlike(x): if type(x)==type(u''): return x else: return str(x)
This seems like a fundamental operation - would it be worth having something similar in the standard library?
Marc-Andre Lemburg replied:
You mean: for Unicode return Unicode and for everything else return strings ?
It doesn't fit well with the builtins str() and unicode(). I'd say, make this a userland helper.
I think this would be helpful to have in the std library. Note that in JPython, you'd already use str() for this, and in Python 3000 this may also be the case. At some point in the design discussion for the current Unicode support we also thought that we wanted str() to do this (i.e. allow 8-bit and Unicode string returns), until we realized that there were too many places that would be very unhappy if str() returned a Unicode string!
The problem is similar to a situation you have with numbers: sometimes you want a coercion that converts everything to float except it should leave complex numbers complex. In other words it coerces up to float but it never coerces down to float. Luckily you can write that as "x+0.0" while converts int and long to float with the same value while leaving complex alone.
For strings there is no compact notation like "+0.0" if you want to convert to string or Unicode -- adding "" might work in Perl, but not in Python.
I propose ustr(x) with the semantics given by Toby. Class support (an __ustr__ method, with fallbacks on __str__ and __unicode__) would also be handy.
Toby Dickenson tdickenson@geminidataloggers.com