> >> 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
--
http://mail.python.org/mailman/listinfo/python-list
