On 8/10/06, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > Guido van Rossum schrieb: > > Hmm... Here's an idea... How about we change unicode-vs-str __eq__ to > > issue a warning (and return False) instead of raising > > UnicodeException? > > I'm in favour of having this __eq__ just return False. I don't think > the warning is necessary, and believe that people will complain about > getting it, but if that is the only way to achieve consensus, > so be it.
Not sure I agree. I think that users would find it disturbing (and it could hide bugs) if u"\xff" == "\xff" returned False without warning while u"\x7f" == "\x7f" returns True. > > A warning would arguably have the same helping effect. (I suspect > > actually that we would have used warnings all along except we didn't > > have the warning framework when unicode was first introduced.) > > I believe we would have neither had we rich comparisons available > at the time. That unicode-vs-str-__eq__ raises an exception is just > a fall-out of not supporting __cmp__ (and it is good that __cmp__ > is not supported - there is no meaningful way to order str/unicode > if the string is not in the system encoding). Maybe. I agree that 3-way compare has no business guessing the ordering of u"\xff" and "\xff". I'm not so sure that if we'd had rich comparison we'd have chosen __eq__ to return False for these. -- --Guido van Rossum (home page: http://www.python.org/~guido/) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com