Tom Anderson wrote: > On Thu, 20 Oct 2005, [EMAIL PROTECTED] 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. -- http://mail.python.org/mailman/listinfo/python-list
