Message11659

Jim: good. I'll go that way then, by which I mean make the unicode methods consistently tolerant. Also for unicode a and b, a + T(b.encode()) = a + b. However:

1. T(a.encode()) + b will still be a T or an error. (It's up to T.__add__.) I thought I should have a unicode.__radd__, but not on second thoughts.

2. Tests for equality should do what CPython does: I'm thinking of the surprises assertEqual() and containers indexed by strings might throw up.

There are a few places around the codebase where "if it's not ascii it's not acceptable". In *some* of them, I think the CPython behaviour will be "if it doesn't decode it's not acceptable". Because any other default encoding is deprecated, this is not really tested in the regression suite. Fixing things here will probably move the focus along to those for a few users.