sqlstring -- a library to build a SELECT statement

[grunar at gmail.com]

> >> Using // for 'in' looks really weird, too. It's too bad you can't
> >> overload Python's 'in' operator. (Can you? It seems to be hard-coded
> >> to iterate through an iterable and look for the value, rather than
> >> calling a private method like some other builtins do.)
> >>
> >
> > // was a bit of a stretch.  I'd initially thought it for the "where"
> > clause, becuase it's lower precedence than ** (I think), and really
> > late at night // kind of looks like a W.  I decided against it because
> > it looks to close to a comment in some other languages.
> >
> > Python "in" clause doesn't seem exploitable in any way--probably a
> > good
> > thing.  I did add a "in_" method (name is arguable), which does the
> > same thing, also a not_in.
>
> What about modifying the overloaded == to produce 'in' if the right-
> hand side is a list? Then you can more easily generate statements
> dynamically:
>
> def makeCond(name):
>      return someOtherCond & (model.table.name == name)
>
> makeCond("foo")
> makeCond(["foo", "bar"])
>
> And it doesn't require two different functions.
>
> As long as there is no case where you might actually want to test if
> a column value equals a list, it should work. Is there? Some DBs
> support an Array type, but in general that might be better handled
> with an Array class, anyway.

This is a great idea, and should be the default behaviour for lists.
It does present a problem if the right hand expression is a SELECT
object, though.  Both of these are valid syntax:

id = (select max(id) from table)
id in (select id from table)

Also, SQLite allows for  column in table_name syntax.  I've never seen
that before, but I wanted to support that, there'd be no way of knowing
in vs. ==.

On this line of thought, what about the += operator?  That might be
more intuative than //.  I could even use -= for not in.

Runar