sqlstring -- a library to build a SELECT statement

[grunar at gmail.com]

Tom Anderson wrote:
> On Thu, 20 Oct 2005, grunar at gmail.com wrote:
>
> > On this line of thought, what about the += operator?  That might be more
> > intuative than //.  I could even use -= for not in.
>
> You're going to have to explain to me how using an assignment operator for
> something other than assignment is intuitive!
>
> -1 on this one from me, i'm afraid.
Point.  I do think it looks strange, because we're used to seeing += in
code.  But the concept is more along the lines of the  == and !=
comparison operators.
Python does expose other nice things, such as &= and %=, which (since
people aren't used to seeing them used much), might be better
candidates.  Does %= seem more agreeable?  (I'm already using % for a
like statement).

So, a statement could look like this:

person ** (
  (person.type_id == 'customer')
  & (person.id %= phone(phone.person_id)))
)

becomes:

select * from person
where person.type_id = 'customer'
and person.id in (select person_id from phone)


> Using 'in' would be good. It does require some truly puke-inducing
> contortions, though; since 'in' calls __contains__ on the right-hand
> operand, and that's likely to be a list, or some other type that's not
> under your control, you have to cross your fingers and hope that whatever
> it is implements __contains__ with equality tests with the probe object on
> the left-hand side and the candidates on the right (as lists do, at least
> in 2.4.1). then, you just have to make your table names do the right thing
> when compared to strings.
>
__contains__, while allowing side-effects on the object in question
(even if though it's on the right), only returns true/false (not a
custom object) afaik, so it breaks in a complex expression  --  (a ==
b) & (c in d), won't work.  You could modify D, but you can't pass that
value to the whole Condition Expression.