> Guido van Rossum wrote:
> >
> > Today, test_string and test_unicode have started to fail. I'm
> > suspicious that this is the result of changes Marc-Andre checked in to
> > make unicode() behave more like str().
> >
> > A little investigation (not that the string test suite makes this easy
> > :-( ) shows that line 133 of string_tests.py checks to make sure that
> >
> > '.'.join('a', u'b', 3)
> >
> > raise an exception. But it now silently casts the 3 to u'3', so the
> > result is u'a.b.3'.
>
> Oops. I forgot to run test_string.py -- I did run test_unicode.py
> and it passes; could be that I need to update the output of that
> test.
I don't know how to tell whether test_unicode.py passes or not from
looking at the output (which is inscrutable to me). All I know is
that regrtest says it fails.
> > Is this really an good idea? Was it an intended side effect?
>
> The intention is to make str() and unicode() behave in the same
> way. It is not a side-effect. unicode() now behaves in the same
> way as str() always did.
Not true. "".join(["a", 3]) raises a TypeError, and this is how it
should be. So I expect that u"".join(["a", 3]) also raises TypeError,
not return u"a3" as it does now.
I urge you to reconsider how this change is implemented. The implied
unicode() call for list items in the join() method is probably just
scratching the surface -- there are likely other places where now
suddenly everything is auto-converted to a unicode string.
--Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4