On 2008-12-09 00:12, Christian Heimes wrote:
> Christian Heimes <lists@cheimes.de> 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
objects.

> Instead I'm proposing PyUnicode_Equal() which returns -1 for errors, 0
> for unequal and +1 for equal. The function follows the semantic of
> http://docs.python.org/c-api/object.html#PyObject_RichCompareBool 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
cases.

> 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
changed.