> I'm am still curious to hear your thoughts on the either sublime or
> crazy idea for a generalized extractor object:
>
> list.sorted(students, key=extract.score)
> list.sorted(animal_weights, key=extract[1])
> groupby(students, key=extract.homeroom)
> groupby(recordtuples, key=extract[0])
This is the same as the "Voodoo" idea; my comments on that are
repeated here:
"""
It is also somewhat weak in that it only addresses lambdas with one
argument, and only allows a single reference to that argument in the
resulting expression, and can't really be made to handle method calls
without more gross notational hacks -- even though it *can* be made to
handle arbitrary binary and unary operators.
Yet, it captures 90% of the use cases quite well. I also wonder if
the simple trick of requiring to call a "constructor" on each use
might not make it more palatable. I.e., instead of writing
map(Voodoo.address[0], database)
you'd write
map(Voodoo().address[0], database)
where you can replace Voodoo with a name of your choice, perhaps
operator.extract -- although I think this is too different to belong
in the operator module. Nick Goghlan showed that a pretty readable
brief explanation *can* be written.
"""
--Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4