cmp and sorting non-symmetric types

Discussion in 'Python' started by Adam Olsen, Nov 13, 2007.

  1. Adam Olsen

    Adam Olsen Guest

    (I've had trouble getting response for collaboration on a PEP.
    Perhaps I'm the only interested party?)

    Although py3k raises an exception for completely unsortable types, it
    continues to silently do the wrong thing for non-symmetric types that
    overload comparison operator with special meanings.

    >>> a = set([1])
    >>> b = set([2, 5])
    >>> c = set([1, 2])
    >>> sorted([a, c, b])

    [{1}, {1, 2}, {2, 5}]
    >>> sorted([a, b, c])

    [{1}, {2, 5}, {1, 2}]

    To solve this I propose a revived cmp (as per the previous thread[1]),
    which is the preferred path for orderings. The rich comparison
    operators will be simple wrappers for cmp() (ensuring an exception is
    raised if they're not merely comparing for equality.)

    Thus, set would need 7 methods defined (6 rich comparisons plus
    __cmp__, although it could skip __eq__ and __ne__), whereas nearly all
    other types (int, list, etc) need only __cmp__.

    Code which uses <= to compare sets would be assumed to want subset
    operations. Generic containers should use cmp() exclusively.


    [1] http://mail.python.org/pipermail/python-3000/2007-October/011072.html

    --
    Adam Olsen, aka Rhamphoryncus
    Adam Olsen, Nov 13, 2007
    #1
    1. Advertising

  2. On Nov 13, 10:51 am, "Adam Olsen" <> wrote:
    > Although py3k raises an exception for completely unsortable types, it
    > continues to silently do the wrong thing for non-symmetric types that
    > overload comparison operator with special meanings.
    > To solve this I propose a revived cmp (as per the previous thread[1]),
    > which is the preferred path for orderings. The rich comparison
    > operators will be simple wrappers for cmp() (ensuring an exception is
    > raised if they're not merely comparing for equality.)
    >
    > Thus, set would need 7 methods defined (6 rich comparisons plus
    > __cmp__, although it could skip __eq__ and __ne__), whereas nearly all
    > other types (int, list, etc) need only __cmp__.


    Am strongly against this. Please don't re-introduce an atrocity to
    solve this non-problem. I realize that it bugs you but AFAICT it never
    is an issue in real programs and I expect it to be even less likely in
    Py3.0 where we get much farther away from sorts of hetrogenous types.
    Also, sort() is no different than hash() or any other function that
    can be fooled by a magic method implementation that doesn't do what
    the calling function expects (for example, a custom __hash__ method
    returning a random number will make it possible to add dict entries
    that cannot be retrieved).

    Also, keep in mind that cmp died for a reason. Having it exist
    alongside rich comparison operations was confusing for users and it
    complicated the heck out of the CPython implementation (and checking
    for it is slow)


    Raymond
    Raymond Hettinger, Nov 13, 2007
    #2
    1. Advertising

  3. Adam Olsen

    Carl Banks Guest

    On Nov 13, 1:51 pm, "Adam Olsen" <> wrote:
    > (I've had trouble getting response for collaboration on a PEP.
    > Perhaps I'm the only interested party?)
    >
    > Although py3k raises an exception for completely unsortable types, it
    > continues to silently do the wrong thing for non-symmetric types that
    > overload comparison operator with special meanings.
    >
    > >>> a = set([1])
    > >>> b = set([2, 5])
    > >>> c = set([1, 2])
    > >>> sorted([a, c, b])

    >
    > [{1}, {1, 2}, {2, 5}]>>> sorted([a, b, c])
    >
    > [{1}, {2, 5}, {1, 2}]
    >
    > To solve this I propose a revived cmp (as per the previous thread[1]),
    > which is the preferred path for orderings. The rich comparison
    > operators will be simple wrappers for cmp() (ensuring an exception is
    > raised if they're not merely comparing for equality.)
    >
    > Thus, set would need 7 methods defined (6 rich comparisons plus
    > __cmp__, although it could skip __eq__ and __ne__), whereas nearly all
    > other types (int, list, etc) need only __cmp__.
    >
    > Code which uses <= to compare sets would be assumed to want subset
    > operations. Generic containers should use cmp() exclusively.



    I second Raymond Hettinger's strong -1 on this.

    I would further suggest that it's the wrong solution even insofar as
    it's a problem. The right solution is to use comparison operators
    only for ordered comparisons, not for subset and superset testing.
    Unfortunately, the rogue operators are already there and in use, so
    the right solution would probably cause more trouble than it would
    save at this point. But it'd still cause less trouble than
    resurrecting the __cmp__ operator.


    Carl Banks
    Carl Banks, Nov 13, 2007
    #3
  4. Adam Olsen

    Paul Rubin Guest

    Carl Banks <>
    > resurrecting the __cmp__ operator.


    I didnd't realize __cmp__ was going. Are we really supposed to
    implement all the rich comparison methods to code an ordered class?
    Or is there some kind of library superclass we can inherit from that
    implements something like __cmp__? What about making __key__ ?
    Paul Rubin, Nov 13, 2007
    #4
  5. On Nov 13, 1:18 pm, Carl Banks <> wrote:
    > The right solution is to use comparison operators
    > only for ordered comparisons, not for subset and superset testing.


    The whole point of the rich comparisons PEP was to be able to override
    the operators for other purposes.



    Raymond
    Raymond Hettinger, Nov 14, 2007
    #5
  6. On Nov 13, 2:54 pm, Paul Rubin <http://> wrote:
    > Carl Banks <>
    >
    > > resurrecting the __cmp__ operator.

    >
    > I didnd't realize __cmp__ was going. Are we really supposed to
    > implement all the rich comparison methods to code an ordered class?
    > Or is there some kind of library superclass we can inherit from that
    > implements something like __cmp__? What about making __key__ ?


    IIRC, you need only define __le__ and __eq__ and the rest get defined
    using a mixin class.


    Raymond
    Raymond Hettinger, Nov 14, 2007
    #6
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Andrea Sansottera

    no cmp field defined in cmp ejb

    Andrea Sansottera, Jul 16, 2004, in forum: Java
    Replies:
    0
    Views:
    384
    Andrea Sansottera
    Jul 16, 2004
  2. Replies:
    11
    Views:
    1,401
    James Kanze
    Jun 7, 2007
  3. George Sakkis

    Replacing cmp with key for sorting

    George Sakkis, Nov 3, 2008, in forum: Python
    Replies:
    8
    Views:
    364
  4. Poor Yorick
    Replies:
    0
    Views:
    466
    Poor Yorick
    Dec 3, 2008
  5. Marc Girod

    mixed cmp operator for sorting

    Marc Girod, Sep 22, 2013, in forum: Perl Misc
    Replies:
    22
    Views:
    357
    Willem
    Oct 9, 2013
Loading...

Share This Page