Fast attribute/list item extraction

[Bengt Richter]

On Tue, 02 Dec 2003 08:19:25 GMT, "Raymond Hettinger" <vze4rx4y at verizon.net> wrote:

>> > Please can we have a name that better expresses the functionality?
>> >
>> > E.g., 'keyfunc', or 'xform' or something that says the method is expecting
>> > a function that will be called with the sorting argument to produce the
>value
>> > used in sorting? "key=" doesn't do it IMO.
>>
>> I agree. To me, the word "key" has deep meaning with respect to hash tables
>> and databases, and reading it as a parameter makes me first think it might
>> require a string or integer. I would prefer something like "sortfunc" or
>> "decorator", but both of your suggestions would be fine by me and preferable
>> to "key".
>
>cmpfunc= and keyfunc= were both suggested by several non-Dutch such as myself.
>
>Then, Guido rightly pointed out that the keywords should just be pithy memory
>joggers. Taken in that light, key= and cmp= do the job nicely.  The definitions
IMO both jog the wrong memories in that context. You might as well say "data"
would do nicely as a name in place of the builtin "file". It jogs the memory that
there's probably data access involved. But it obscures the "what kind"
which is what "file" communicates.

If you want pithy, then at least tack on a hint, e.g., "keyf"

>and details are best left to docstrings and regular docs.  Besides, after
>learning the new DSU key just once, we *know* what kind of function is supposed
IMO the "learning just once" argument is a Perl argument, once you accumulate a few
features with misleading or no mnemonics ;-)

>to go there. Further, when reading code, you get the additional context of
>seeing which function was actually used:
>
>   logentries.sort(key=lambda e: e.juliandate)      # looks like a key function
>to me
Excuses, rationalizations. I don't wan't to incite a contest, but IMO "key=" is misleading ;-)

Regards,
Bengt Richter