Michael Urman writes: > I strongly believe that unicode vs str here is the symptom and not the > actual problem. The comparison between two non-us-ascii str/unicode > instances is but one of many ways to raise an exception during > comparison. [... example ...] > Yes this is made up code. But I'm not arguing for a feature; I'm > arguing for backwards compatibility. Because we do not know where > these legitimate uses are, we cannot evaluate their likelihood to > exist nor the level of breakage they will cause. If we make this a > warning for any exception, we can satisfy both imagined camps. Those > in Armin's position can make that warning raise an exception while > debugging, and those using it on purpose can squash it.
See also my example from the beginning of this thread (http://mail.python.org/pipermail/python-dev/2006-August/067978.html). The example wasn't from real code, but it WAS quite plausible -- straightforward use of a popular Python Cookbook recipe. But we seem to have reached a rough consensus: Later, Guido writes: > How about we change unicode-vs-str __eq__ to > issue a warning (and return False) instead of raising > UnicodeException? [... Marc-Andre Lemburg agrees ...] > Great! Now we need someone to volunteer to write a patch (which should > include doc and NEWS updates) in time for beta 3 (Aug 18). I don't *strongly* object to this consensus, but if you haven't glanced at my original example, take a look - it might convince you. The proposed solution will not help with my example. I'm not sure the motivation for breaking code like that example -- the bug-hunting motivation is satisfied by issuing a warning as Michael Urman proposes, then use an exception after one more release when people have had time to fix their code. -- Michael Chermside _______________________________________________ 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