Changes by Ezio Melotti ezio.melo...@gmail.com:
--
priority: - normal
stage: - needs patch
type: - feature request
versions: +Python 2.7, Python 3.2 -Python 2.6, Python 3.0
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue4328
R. David Murray rdmur...@bitdance.com added the comment:
Actually, I've already fixed this for 2.7 (issue 1680159) by letting the
UnicodeDecodeError propagate upward. I don't think making 'f' in u'foo'
an error would be a good idea.
Unless I'm mistaken the py3 behavior is correct. If someone
Martin v. Löwis [EMAIL PROTECTED] added the comment:
No patch has been proposed yet, so un-targetting for bugfix branches.
--
nosy: +loewis
versions: -Python 2.4, Python 2.5, Python 2.5.3
___
Python tracker [EMAIL PROTECTED]
Terry J. Reedy [EMAIL PROTECTED] added the comment:
| but then it works with:
| b'f' in 'foo'
| True
Not True in 3.0rc3. Same message as you quoted:
'in string' requires string as left operand, not bytes
bytes + string fails too
--
nosy: +tjreedy
New submission from Ezio Melotti [EMAIL PROTECTED]:
With Python 2.x:
'à' in u'foo'
Traceback (most recent call last):
File stdin, line 1, in ?
TypeError: 'in string' requires string as left operand
'à' in u'xàx'
Traceback (most recent call last):
File stdin, line 1, in ?
TypeError: 'in
Matthew Barnett [EMAIL PROTECTED] added the comment:
The left operand is a bytestring and the right operand is a unicode
string, so it makes sense that it raises an exception, although it would
be clearer if it said 'in string' requires unicode string as left
operand.
I agree that if it's going
Ezio Melotti [EMAIL PROTECTED] added the comment:
Usually, when you do operations involving unicode and normal strings,
the latter are coerced to unicode using the default encoding. If the
codec is not able to decode the string a UnicodeDecodeError is raised. E.g.:
'à' + u'foo'
Traceback (most
