Re: python 3's adoption

[mdj]

On Jan 29, 12:21 pm, Steven D'Aprano  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)
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: python 3's adoption

[mdj]

On Jan 29, 9:47 am, Paul Boddie  wrote:
> On 27 Jan, 13:26, Xah Lee  wrote:
>
>
>
> > So, for practical reasons, i think a “key” parameter is fine. But
> > chopping off “cmp” is damaging. When your data structure is complex,
> > its order is not embedded in some “key”. Taking out “cmp” makes it
> > impossible to sort your data structure.
>
> What would annoy me if I used Python 3.x would be the apparent lack of
> the __cmp__ method for conveniently defining comparisons between
> instances of my own classes. Having to define all the rich comparison
> methods frequently isn't even as much fun as it sounds.

OT, but you can always define the other operators in terms of a cmp
and mix it in, restoring the original behaviour. Unfortunately it
won't restore the original performance until someone comes to their
senses and restores __cmp__

Matt
-- 
http://mail.python.org/mailman/listinfo/python-list