A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2000-July/006627.html below:

[Python-Dev] decoding errors when comparing strings

[Python-Dev] decoding errors when comparing strings [Python-Dev] decoding errors when comparing stringsFredrik Lundh Fredrik Lundh" <effbot@telia.com
Sat, 15 Jul 2000 20:30:07 +0200
paul wrote:
> As soon as you find a character out of the ASCII range in one of the
> strings, I think that you should report that the two strings are
> unequal.

sounds reasonable -- but how do you flag "unequal" in cmp?  which
value is "larger" if all that we know is that they're different...

> We can't have exceptions popping out of dictionaries and other "blind
> compare" situations. Is there any precedent for throwing an exception
> on cmp?

not really.  it's a bit amusing that

    "a" =3D=3D x

works for all built-in types, except
unicode strings...

(not to mention that "a" < x works,
in a way...)

> Also, is it really necessary to allow raw non-ASCII characters in =
source
> code though? We know that they aren't portable across editing
> environments, so one person's happy face will be another person's left
> double-dagger.

I suppose changing that would break code.  maybe it's time
to reopen the "pragma encoding" thread?

(I'll dig up my old proposal, and post it under a new subject).

</F>




RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4