Remove the cmp_to_key() helper function

[vperic]

A helper function, cmp_to_key, was introduced with commit d68d33. The problem was that Python 3 no longer supports the cmp() function, and it cannot be used as an argument in sort() or sorted(). The idea behind the helper function was to avoid those issues for the moment and leave it for the future. As Python 3 support is (mostly) in now, the future is now. :)

cmp_to_key should not be used any more. This probably means changing our __cmp__ methods to rich comparisons but I'm not sure yet so lets keep this as a first goal. I will work on this. I do consider it low priority, though, as it doesn't really impact any functionality. 

See also what Aaron said in this comment[1]: "It appears that in a lot of cases, compare_pretty is being used with cmp_to_key.  This is wrong.  It should just use default_sort_key (or some variation of sort_key())."

Original issue for #5773: http://code.google.com/p/sympy/issues/detail?id=2674
Original author: https://code.google.com/u/108713607268198052411/
Original owner: https://code.google.com/u/108713607268198052411/

[asmeurer]

**Blocking:** 4590  

Referenced issues: #4590
Original comment: http://code.google.com/p/sympy/issues/detail?id=2674#c1
Original author: https://code.google.com/u/asmeurer@gmail.com/

[vperic]

Well, this was embarrassingly simple to fix actually. As you said, most of the uses of Basic.compare_pretty can be replaced seamlessly with default_sort_key, and I've done just that in a branch. Unfortunately, there's a use in core/mul.py that cannot be just replaced with default_sort_key. Per a comment there, it's used just to assure a canonical ordering, but if I use default_sort_key, I get the following error (twice in two different core tests):

  File "/home/vperic/devel/sympy/sympy/core/tests/test_expr.py", line 183, in test_leadterm
    assert (1/x**2+1+x+x**2).leadterm(x)[1] == -2
  File "/home/vperic/devel/sympy/sympy/core/expr.py", line 1860, in leadterm
    raise ValueError("cannot compute leadterm(%s, %s), got c=%s" % (self, x, c))
ValueError: cannot compute leadterm(x**2 + x + 1 + x**(-2), x), got c=x**(-2)

As this is kinda deep down the core code I'm a little confused. Aaron, do you have any ideas? That's the last use of cmp_to_key. (I guess when I was first converting, this was what I tried to convert and gave up, instead preferring to add the cmp_to_key wrapper)

In any case, I've pushed my work to my github. It's on top of smichr's pull request 590 as those errors were annoying me. See it at: https://github.com/vperic/sympy/tree/cmp_to_key

**Status:** Started  

Original comment: http://code.google.com/p/sympy/issues/detail?id=2674#c2
Original author: https://code.google.com/u/108713607268198052411/

[vperic]

Aaron, I've applied your patch ( https://gist.github.com/1208773 ) but it unfortunately breaks other things, see the attached file for the log. I'll mess around with this a bit more. I applied your other patch and fixed the Python 3 issue, though.

**Cc:** asmeurer@gmail.com  

Original comment: http://code.google.com/p/sympy/issues/detail?id=2674#c3
Original author: https://code.google.com/u/108713607268198052411/

[asmeurer]

Can you push this up to a branch?

Original comment: http://code.google.com/p/sympy/issues/detail?id=2674#c4
Original author: https://code.google.com/u/asmeurer@gmail.com/

[vperic]

Check the cmp_to_key branch. Expect rebases. Thanks for taking a look at this, I'm a bit lost.

Original comment: http://code.google.com/p/sympy/issues/detail?id=2674#c5
Original author: https://code.google.com/u/108713607268198052411/

[vperic]

Hmmm. Mateusz did some recent work related to this so I have to redo my branch from scratch (not yet ready). Still, looking at his patch aa94e72 (deprecate Basic.compare_pretty()) it occurs to me that we cannot remove cmp_to_key as long as we have to support old ordering -- I'm not sure we can guarantee the ordering is "old" if I change the function with whatever, and we can't have Python 3 support with the cmp_to_key function. So, my question is: Could we simply not define the old ordering for Python 3 and be done with it? The reasoning being, as the old ordering was already "old" by the time we got Python 3 support, then everyone on Python 3 should be using the "new" ordering anyway. Thoughts?

Of course, maybe I'm just missing some obvious fix for this? I could just replace the relevant line with default_sort_key, but obviously that's not "old" ordering anymore. Mateusz, what do you think?

**Cc:** matt...@gmail.com  

Original comment: http://code.google.com/p/sympy/issues/detail?id=2674#c6
Original author: https://code.google.com/u/108713607268198052411/

[asmeurer]

That's a reasonable possibility. Otherwise, we just keep cmp_to_key around until we drop the old ordering.

To quote Mateusz on the other issue, "The old order will most certainly die naturally when Py3k port is ready, but I don't mind removing it earlier."

Original comment: http://code.google.com/p/sympy/issues/detail?id=2674#c7
Original author: https://code.google.com/u/asmeurer@gmail.com/

[vperic]

**Blocking:** -1491  

Original comment: http://code.google.com/p/sympy/issues/detail?id=2674#c8
Original author: https://code.google.com/u/108713607268198052411/

[vperic]

Alright, so based on the other issue, we'll drop old ordering two versions from now, so this is blocked on that. 

Or, again, I could just not define it in Python 3 if we consider removing cmp_to_key that important.

**Blockedon:** 1491  

Original comment: http://code.google.com/p/sympy/issues/detail?id=2674#c9
Original author: https://code.google.com/u/108713607268198052411/