This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author lemburg
Recipients amaury.forgeotdarc, benjamin.peterson, brett.cannon, christian.heimes, georg.brandl, lemburg, mark.dickinson, pitrou, rhettinger
Date 2008-12-08.23:53:21
SpamBayes Score 9.05159e-12
Marked as misclassified No
Message-id <>
In-reply-to <>
On 2008-12-09 00:12, Christian Heimes wrote:
> Christian Heimes <> added the comment:
> Marc-Andre, how  do you like a function PyUnicode_Equal() instead of
> PyUnicode_Compare()?
> The old PyUnicode_Compare() function returns -1 for smaller value and
> errors, 0 for equality and +1 for larger value. I find it confusing to
> have one function that follows the old PyObject_Compare() behavior.

For Unicode objects you don't have the issues with general rich
comparisons. Unicode objects only know <, = and >, so the C approach
of using -1, 0, +1 for these results will work just fine.

It doesn't in the general case, where comparisons can return arbitrary

> Instead I'm proposing PyUnicode_Equal() which returns -1 for errors, 0
> for unequal and +1 for equal. The function follows the semantic of
> nicely.

Yes, but for sorting Unicode (in C) and other quick checks that rely on
lexical ordering you need checks for < and > as well.

It's better to have just one C API than 3 or 5 to cover all comparison

> About your proposal for cmp(), where should we put the method? I'm -0.5
> on builtins.

Good question.

It is in the builtins in Python 2.x, so keeping it there would make
porting easier, but then it's probably better to put it somewhere else
to make people aware of the fact that the underlying machinery has
Date User Action Args
2008-12-08 23:53:23lemburgsetrecipients: + lemburg, brett.cannon, georg.brandl, rhettinger, amaury.forgeotdarc, mark.dickinson, pitrou, christian.heimes, benjamin.peterson
2008-12-08 23:53:22lemburglinkissue1717 messages
2008-12-08 23:53:21lemburgcreate