Fast attribute/list item extraction

Robert Brewer fumanchu at amor.org
Mon Dec 1 13:44:42 EST 2003


> >[Peter Otten]
> >> > extract[1]
> >> > extract["key"]
> >
> >[Robert Brewer]
> >> I'm having a hard time seeing the use cases, given that I find
> >> most of them more readable if done with list comprehensions
> >> or good ol' for loops.
> >
> >Peter's post focused on implementation instead of the context.
> >
> >For Py2.4, the list.sort() will have an optional key 
> argument that encapsulates
> >the decorate/sort/undercorate pattern.  For example, here is 
> the new fastest way
> >to have a case insensitive sort leaving the original case intact:
> >
> >>>> words = 'The quick BROWN fox JumPed OVER the LAzy dog'.split()
> >>>> words.sort(key=str.lower)
> 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.

Okay, I understand better now. I didn't realize the DSU-nature of the
extra sort param, or the function-nature of 'key'. I was
searching/hoping for a PEP on it. Had to catch up on python-dev reading
instead, which also informed me you proposed the decorator param in the
first place, Raymond. ;)

Given all of that, the extract() implementation looks fine. But now that
I've dug through it, extract() begins to look more and more like a
special case of general currying. Not sure I wouldn't rather just have
curry, whether builtin, library function, or my own. Example:

def printSeq(seq, extractor):
    for item in seq:
        print extractor(item),
    print
printSeq(attrSample, rightcurry(getattr, 'y'))

IMO, it's just as readable but more powerful.


Robert Brewer
MIS
Amor Ministries
fumanchu at amor.org





More information about the Python-list mailing list