[ python-Bugs-971106 ] Comparisons of unicode and strings raises UnicodeErrors

SourceForge.net noreply at sourceforge.net
Mon Jun 14 13:32:30 EDT 2004


Bugs item #971106, was opened at 2004-06-11 15:07
Message generated for change (Comment added) made by lemburg
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=971106&group_id=5470

Category: Unicode
Group: Python 2.3
Status: Closed
Resolution: Wont Fix
Priority: 5
Submitted By: Christian Theune (ctheune)
Assigned to: M.-A. Lemburg (lemburg)
Summary: Comparisons of unicode and strings raises UnicodeErrors

Initial Comment:
When comparing unicode and strings the implicit conversion
will raise an exception instead of returning false. See the
example later on.

We (Christian Theune and Jim Fulton) suggest that
if the ordinary string can't be decoded,  that False should
be returned.  This seems to be the only sane approach 
given's Python's policy of implicitly converting strings
to unicode using a default encoding.


Python 2.3.4 (#1, Jun 10 2004, 11:08:42) 
[GCC 3.3.3 20040412 (Gentoo Linux 3.3.3-r6,
ssp-3.3.2-2, pie-8.7.6)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> class Elephant:
...     pass
... 
>>> e1 = Elephant()
>>> e1 == 5
False
>>> u"asdf" == "asdfö"
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
UnicodeDecodeError: 'ascii' codec can't decode byte
0xf6 in position 4: ordinal not in range(128)
>>> e1 == "asdfö"
False
>>> e1 == u"asdfö"
False
>>> 


----------------------------------------------------------------------

>Comment By: M.-A. Lemburg (lemburg)
Date: 2004-06-14 19:32

Message:
Logged In: YES 
user_id=38388

Here's an example to make you think this over:

>>> u"äöü" == "äöü"
False

Try to explain that to a novice :-)

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-06-14 19:17

Message:
Logged In: YES 
user_id=31435

I think some noise would be a good thing <wink>.  Really!  
Comparisons in Python are a mess now, and it would be good 
to hammer out a (more) consistent story.

Note that the new-in-2.3 Python sets.* and datetime.* 
types do some of each for comparisons against incompatible 
types:  for <=, <, >, and >=, they raise an exception.  For 
== they return True, and for != they return False.  Guido 
gave a lot of thought to those at the time, and it's no 
coincidence that these new types act the same way.

But older types don't.  Maybe the new idea was a mistake.  
Maybe the older types should change.  Maybe there are good 
reasons to keep them acting differently.  Some noise about 
all this is really needed before Python 3.

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-06-14 19:05

Message:
Logged In: YES 
user_id=38388

You won't get my approval on this one, that's for sure... then
again I'm not sure how much say I have on these things on
python-dev anymore four years after having led it's design.

As data point, there have been discussions about raising 
exceptions in cases where types don't match and there is no 
support for the given type combination like in your e1 == 5 
example, so maybe stirring up noise isn't the best strategy
in this case :-)

----------------------------------------------------------------------

Comment By: Tim Peters (tim_one)
Date: 2004-06-14 18:48

Message:
Logged In: YES 
user_id=31435

Christian, you and/or Jim would need to make the case on 
Python-Dev to change this behavior, and get Guido to agree.  
The current behavior isn't an accident -- it's functioning as 
documented and designed.  Changing existing behavior isn't 
easy (and shouldn't be easy ...).

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-06-14 18:21

Message:
Logged In: YES 
user_id=38388

In that case I'll have to close the request as "Won't fix":
comparisons can raise exceptions and if you're comparing
apples and eggs you should get an exception instead of
a misleading result which only hides programming errors.

Sorry.

----------------------------------------------------------------------

Comment By: Christian Theune (ctheune)
Date: 2004-06-14 18:16

Message:
Logged In: YES 
user_id=100622

That's what Jim and I found to be the best solution (for now) 

----------------------------------------------------------------------

Comment By: M.-A. Lemburg (lemburg)
Date: 2004-06-14 18:06

Message:
Logged In: YES 
user_id=38388

I'm not sure what you are suggesting here... do you want
u"asdf" == "asdfö" to return False ?

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=971106&group_id=5470



More information about the Python-bugs-list mailing list