GeezerVison

> But regardless of where Barry's Unicode objects come from, his point
> remains open.  Do we consider the library's lack of Unicode awareness a
> bug, or do we drop any pretence of string and unicode objects being
> interchangeable?
> 
> As a related issue, do we consider that str(unicode_ob) often fails is a
> problem?  The users on c.l.py appear to...
> 
> Mark.

Exactly.

I want unicode from Mark's code, unicode is goodness.

But the principle of least astonishment may well be broken in the library,
indeed in the language.

It took me 40 minutes to prove that the unicode came from Mark's code and
I know the code involved intimately. Debugging these failures is tedious.

I don't have an opinion as to the best resolution yet.

One option would be for Mark's code to default to string. But that does not
help once someone chooses to enable unicode in Mark's code.

Maybe '%s' % u'x' should return 'x' not u'x' and u'%s' % 's' return u's'

Maybe 's' + u'x' should return 'sx' not u'sx'. and u's' + 'x' returns u'sx'

The above 2 maybe's would have hidden the problem in my code, baring exceptions.

	Barry