[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[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.

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) 
expression.

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 mailing list