At 04:18 PM 11/30/03 -0800, Guido van Rossum wrote: > > How about: > > > > extract(attr='grade') > > extract(item=2) > > extract(method='foo') # returns the result of calling 'ob.foo()' > > > > And following the pattern of Zope's old "query" package: > > > > extract(extract(attr='foo'), attr='bar') # extracts ob.foo.bar > > extract(extract(item=10), method='spam') # extracts ob[10].spam() > > > > i.e., the first (optional) positional argument to extract is a function > > that's called on the outer extract's argument, and the return value is > then > > used to perform the main extract operation on. > >I'm not sure what the advantage of this is. The chaining part, or the idea at all? For the idea in general, I was just proposing a more explicit form of the last API proposal. For the chaining part, well, my use case is the same as the old Zope query library: being able to compose operators to craft OO queries from a high level description. No reason that needs to go in the standard library, but as long as we were dreaming, I figured I might help implement it if it solved enough problems for me. :) (Without the chaining part, I don't really care if there's a standard library 'extract()' or not, since I'll still need to write a chaining one sooner or later.) > It seems more typing, >more explanation, probably more code to implement (to check for >contradicting keyword args). Yes. Really the whole extract thing isn't that useful, except to get extra speed over using 'lambda x: x.foo' or whatever, which is what I'd probably use in any code that wasn't composing functions or compiling an OO query language. :)
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