On Oct 19, 2005, at 11:55 PM, [EMAIL PROTECTED] wrote:
>
> Jason Stitt wrote:
>
>>
>> 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.
- Jason, fingers crossed that all this black magic doesn't affect
one's chances in the afterlife ;)
--
http://mail.python.org/mailman/listinfo/python-list
