[Python-Dev] Re: "groupby" iterator
Phillip J. Eby
pje at telecommunity.com
Wed Dec 3 11:44:33 EST 2003
At 07:00 AM 12/3/03 -0800, Guido van Rossum wrote:
>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, database)
> map(Voodoo().address, 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.
What if it was possible to use, e.g:
arg(0).foo + arg('somekeyword').bar
That is, have the constructor take an argument position number or kwarg
name (perhaps defaulting to 0 for convenience)? Then, you could create
expressions that replaced multi-argument lambdas. Then, the only things
missing are ways to construct structure expressions like
[arg(0).foo,arg(1).bar]. For that, you'd also need an 'args', and to
invoke other functions you'd need an argapply. Yuck.
I guess that limiting these "argument expressions" to what one might find
in an SQL 'select' or 'where' clause (minus nested selects, of course)
might not be a bad thing.
There might also be a problem with supporting all binary
operators... using 'not in' would break, I think, since there isn't a
__notcontains__ method. :) You'd have to use e.g. ~(arg(0) in [1,2,9])
instead of 'arg(0) not in [1,2,9]' or 'not arg(0) in [1,2,9]'.
Anyway, the implementation of binary operators would also need to check if
the 'other' argument was another "argument expression", and if so return a
slightly different result than it would for a non-argument (i.e. constant)
Interestingly, all this is quite similar to Ian Bicking's SQLObject, which
uses expressions of this sort to represent SQL as Python code.
More information about the Python-Dev