Raymond Hettinger: > Psychologically, the thing that I find to be interesting is > that beginners and intermediate users seem to take to key > functions more readily than old timers. The key function seems > to be an easy thing to teach (perhaps because that's the > way Excel sorts and the way SQL sorts, or perhaps it is because > problem statements seem to arise in the form of "sort by this, > then by that" instead of "here's how two objects should be > compared"). > > In contrast, some people who have have had deep experience with > cmp functions may tend to first think of cmp solutions and then > have a harder time seeing solutions with key functions. If you > grew-up on C's qsort() like I did, then a key function may not > be the first thing that pops into your head.
I love the 'key', it makes my code simpler and it's simpler to understand. I am not opposed to the idea of keeping cmp, that in some rare cases may be useful or more natural. The problem is that if you allow to use the cmp, lot of programmers will use it straight away, not even bothering to know what that strange 'key' argument may be useful for. And they miss the how much handy 'key' is. I am having a very hard type (despite my implementation, explanations, etc) explaining to D programmers why for a flexible general-purpose function a key function argument is often better. They in the end have added something like that in the std lib, but with a weird name like SchwartzSort that's surely not the first standard sort they look for... this is bad. So a funny solution to this situation may be the following: to keep only 'key' in the sort/sorted for few years, so the community of Python programmers gets used to 'key' only, and then put 'cmp' back in, for the special cases ;-) Bye, bearophile -- http://mail.python.org/mailman/listinfo/python-list
