derivation: sick Python trick of the week

[Robert Brewer]

I wrote:
> > In a fit of mad-scientist genius (get out the pitchforks 
> and torches), I
> > wondered if it might be faster to let Python do *all* the 
> parsing, and
> > just watch it work and take notes. That's what the code 
> below does. The
> > sick and twisted part is how one invokes this technique:

and Greg Ewing answered:
> It's not really all that sick, or at least it's not a new
> idea. I'm sure there's at least one DB module out there
> somewhere that uses this technique.

Figured it wasn't new. It's still hideous. :)

> > Yes, in line two we run comparisons and boolean operations on
> > non-existent attributes of x, and discard the results! Sick.
> 
> That part is perhaps a bit too twisted. It's not really
> necessary, you could just as well design it so you say
> 
>     expr = (x.a == 3) & ((x.b > 1) | (x.b < -10))

Yes, and I had done this already just to help wrap my brain around it.
There's still nothing useful about the return value (since my example
was quasi-LL, not recursive descent), but it's easier to read.

>  > And it's
>  > *far* from obvious that 'x.a' should reduce to just 'a'.
> 
> In the case of database queries, you can make this seem
> much more natural by having 'x' represent some meaningful
> object such as a table.
> 
>     db = open_database("favourite_fruits")
>     fruits = db.fruits
>     query = (fruits.kind == "apple") && (fruits.tastiness >= 3)

This is much more important in the version I'm keeping (based on
compiler.Transformer output), since there I can write:

[(x.kind, x.tastiness) for x in fruits if x.kind == "apple"]

and end up with:

SELECT fruits.kind, fruits.tastiness FROM fruits WHERE fruits.kind =
'apple'

This is getting used initially in a caching object server, so I have to
be able to apply the same logic to both 1) a dictionary of cached Python
objects, and 2) a database query.

> > I had to replace boolean 'and' and 'or' with binary calls 
> in order to
> > override them, and 'not' with 'neg'. That makes it even sicker.
> 
> Yes, that's the main nuisance with this technique. I have
> a PEP idea floating around to make and/or/not overridable,
> for this very purpose. Hmmm... does that make me sick?-)

Not sick. I personally wouldn't support the PEP based on this use case.
;) But I could see reasonable uses for it, mostly along these lines of
"paralleling a process" with another, observing process.

Thanks for the comments!


Robert Brewer
MIS
Amor Ministries
fumanchu at amor.org