Re: python 3's adoption

[mdj]

On Jan 29, 9:47 am, Paul Boddie p...@boddie.org.uk wrote:
 On 27 Jan, 13:26, Xah Lee xah...@gmail.com 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

Re: python 3's adoption

[mdj]

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