On Thu, Mar 24, 2011 at 09:06:44AM -0600, Ian Kelly wrote: > On Thu, Mar 24, 2011 at 3:23 AM, Antoon Pardon > <antoon.par...@rece.vub.ac.be> wrote: > > Sure I can do that. I can do lots of things like writing a CMP class > > that I will use as a key and where I can implement the logic for > > comparing the original objects, which I otherwise would have put in a > > cmp function. I thought this wasn't about how one can get by without > > the cmp argument. This was about cases where the cmp argument was the > > more beautiful or natural way to handle this case. > > That's not what you wrote before. You wrote "I can't do the sort in > multiple steps." I was just responding to what you wrote.
That is because I tend to assume some intelligence with those I communicate with, so that I don't need to be pedantly clear and spell everything out. However since that seems to be a problem for you I will be more detailed. The original poster didn't ask for cases in which cmp was necessary, he asked for cases in which not using cmp was cumbersome. I gave a case where not using cmp was cumbersome. a tuple where you want it sorted with first item in descending order and second item ascending. You then responded, that you could solve that by sorting in multiple steps. The problem with this response is that how items are to be compared can be decided in a different module from where they are actually sorted. So if we would accept this MO, this would mean that any module that needed to sort something according to a provided key, would need to provide for the possibility that the sorting would have to be done in multiple steps. So, in order to avoid complexity in the internal python sort, we would increase the complexity of all library code that would need to sort things in a by the user provided way and didn't want to barf in such an event. So when I wrote I couldn't do that, I implicitly meant if you want a less cumbersome solution than using cmp, because your solution would make all library code more cumbersome. > > I think I have provided such a case. If you don't agree then > > don't just give examples of what I can do, argue how your solution > > would be a less ugly or more natural way to handle this. > > Well, the alternative is to generate the cmp function from the > externally selected keys dynamically at runtime, is it not? Something > like this: > > def get_cmp(keys): > def cmp(a, b): > for (key, reversed) in keys: > if reversed: > result = cmp(key(b), key(a)) > else: > result = cmp(key(a), key(b)) > if result != 0: > return result > return result > return cmp > > I fail to see how that is any more natural than my solution, unless > you have another way of doing it. And it's certainly not going to be > any faster. First of all, there is no need for a dynamical generated cmp function in my provided case. My cmp fumction would simply look like this: def cmp(tp1, tp2): return cmp(tp2[0], tp1[0]) or cmp(tp1[1], tp2[1]) Second, there is not only the question of what is more natural, but there is also the question of how you are spreading the complexity. Your first solution would mean spreading the complexity to all library code where the user could provide the order-relation of the items that would then be sorted within the library. This alternative of your, even if too complicated than needed would mean that libary code could just use the sort method and the complicated code is limited to those specific items that need it. -- Antoon Pardon -- http://mail.python.org/mailman/listinfo/python-list
