Fix adding functions to CommandChainDispatcher with equal priority on Py 3

[takluyver]

Includes a test.

Closes gh-1916

[fperez]

Code looks clean, running test_pr now

[takluyver]

Race you with the tests ;-)

[minrk]

This looks solid, but just for my own edification, why use operator.itemgetter(0) instead of lambda t: t[0]?

[takluyver]

Test results for commit 2e28c7b merged into master
Platform: linux2

• python2.7: OK (libraries not available: rpy2 tornado)
• python3.1: OK (libraries not available: cython matplotlib numpy pymongo qt rpy2 wx wx.aui zmq)
• python3.2: OK (libraries not available: cython pymongo rpy2 wx wx.aui)

Not available for testing: python2.6

[fperez]

Test results for commit 2e28c7b merged into master
Platform: linux2

• python2.7: OK
• python3.2: OK (libraries not available: cython matplotlib pymongo rpy2 wx wx.aui)

Not available for testing: python2.6, python3.1

[fperez]

I had the same thought as @minrk, decided not to really bring it up, but I also think the lambda in this case is cleaner than the rather awkward-looking itemgetter call. Order epsilon complaint, though :)

I'm OK with it either way, otherwise I think this can go in.

[takluyver]

I understand that itemgetter is faster - not that it makes a jot of difference here, but just as general 'best practices'. On reflection, I think I'd actually prefer the lambda here as well. I'll commit that and then merge.

[minrk]

Quick test shows it is a good deal faster:

In [17]: import operator
In [18]: f = operator.itemgetter(0)
In [19]: g = lambda t: t[0]
In [20]: chain = [(i,'foo') for i in range(1000)]

In [21]: %timeit chain.sort(key=f)
10000 loops, best of 3: 163 us per loop

In [22]: %timeit chain.sort(key=g)
1000 loops, best of 3: 289 us per loop

So almost twice as fast. But that's still only saving 0.1ms on a thousand items (already sorted).

[takluyver]

I guess it's the overhead of an repeatedly making an extra stack frame for the lambda - the operator module is compiled, so the sort can stay in C code.