python 3's adoption

[mdj]

On Jan 29, 12:21 pm, Steven D'Aprano <st... at REMOVE-THIS-
cybersource.com.au> wrote:

> "Comes to their senses"?
>
> There's nothing you can do with __cmp__ that you can't do better with
> rich comparisons, and plenty that rich comparisons can do that __cmp__ is
> utterly incapable of dealing with. __cmp__ is crippled since it can only
> be used for defining classes where the operators < etc return flags. It
> can't be used if you want to implement some other behaviour for the
> operators. E.g. here's a silly example:

[example snipped]

Okay, but I think that overloading to change the semantic meaning of
operators is another issue, and one that there's a great deal of
difference of opinion on. Personally, I find arbitrarily redefining
operators with well understood semantics to mean something totally
different to be poor style, and those who disagree would find my style
poor :-)

> Having two mechanisms for implementing comparisons is unnecessary. It
> adds complications to the language that we are better off without. The
> only advantage of the obsolete __cmp__ is that lazy programmers only need
> to write one method instead of six. This is an advantage, I accept that
> (hey, I'm a lazy programmer too, that's why I use Python!) but it's not a
> big advantage. If you really care about it you can create a mixin class,
> a decorator, or a metaclass to simplify creation of the methods. For
> example, a quick and dirty decorator:

I agree it's unnecessary, but deleting a time tested idiom in the name
of consistency seems excessive to me. Is there not a compromise? For
those of us who prefer limiting operator overloads to semantically
compatible cases the extra flexibility is seldom necessary, and the
price extracted in terms of inconvenience is therefore quite high. You
can (as I mentioned and you demonstrated) work around the problem, but
I'd hate to see 50 different implementations of a common idiom wasting
brain space in future projects.

Matt

(Note I remove the crosspost to comp.lang.lisp where I saw this - one
of the reasons I love lisp is that discussions like this become
totally unnecessary)