derivation: sick Python trick of the week
Robert Brewer
fumanchu at amor.org
Mon Feb 23 02:37:21 EST 2004
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
More information about the Python-list
mailing list