➜

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-09.00:10:35
SpamBayes Score 2.437886e-07
Marked as misclassified No
Message-id <493DB779.40802@egenix.com>
In-reply-to <1228780732.27610.2.camel@localhost>
Content 
On 2008-12-09 00:58, Antoine Pitrou wrote:
> Antoine Pitrou <pitrou@free.fr> added the comment:
> 
> I wrote:
>> IMO PyUnicode_Compare() should be replaced by a hypothetical
>> PyObject_RichCompare(), which allows to take shortcuts when comparing
>> strings of different length and a Py_EQ or Py_NE comparison is requested.
> 
> ... and I didn't even remember that PyUnicode_RichCompare() already
> exists. So let my proposal be to enable those optimizations inside the
> existing PyUnicode_RichCompare(), and dump PyUnicode_Compare().

What for ? What does this have to do with removing __cmp__ ?
Why do you want to break the C API for no apparent reason ?

I've designed the Unicode C API to be a rich API and would like
it to stay that way.
History
Date User Action Args
2008-12-09 00:10:36lemburgsetrecipients: + lemburg, brett.cannon, georg.brandl, rhettinger, amaury.forgeotdarc, mark.dickinson, pitrou, christian.heimes, benjamin.peterson
2008-12-09 00:10:35lemburglinkissue1717 messages
2008-12-09 00:10:35lemburgcreate