sqlstring -- a library to build a SELECT statement
grunar at gmail.com
grunar at gmail.com
Fri Oct 21 01:04:01 CEST 2005
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 !=
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
So, a statement could look like this:
person ** (
(person.type_id == 'customer')
& (person.id %= phone(phone.person_id)))
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.
More information about the Python-list