On Apr 11, 2007, at 3:22 PM, Ants Aasma wrote:
> > I'd say this is a definite bug. The semantics of col.in_(list) should > be column value equals any of the values in the list. For an empty > list it should be a constant false, because no value exists in an > empty list, not even an missing value (null). What makes it a bit > tricky is the fact that for null values the result should actually > also be null. When straight .in_() is used it doesn't really matter, > but when the negation is used then it starts to matter. That's because > not_(col.in_()) should be the equivalent of COL IS NOT NULL. I think > the best way would be to compile it to COL != COL, it has the correct > behaviour when negated as well as not negated. Diff follows: > Index: lib/sqlalchemy/sql.py > =================================================================== > --- lib/sqlalchemy/sql.py (revision 2494) > +++ lib/sqlalchemy/sql.py (working copy) > @@ -895,5 +895,5 @@ > def in_(self, *other): > if len(other) == 0: > - return self.__eq__(None) > + return self.__ne__(self) > elif len(other) == 1 and not hasattr(other[0], > '_selectable'): > return self.__eq__(other[0]) > right well thats one way to look at it, i.e. that we should interpret the meaning of "IN ()" in some special way. the current behavior is based upon my going with that approach a couple of years ago (and getting it wrong...suprise). but why dont we want to just have it compile just as it says - to "IN ()" on the database side ? im not sure if trying to guess what the user means here is the best approach (refuse the temptation to guess...) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~----------~----~----~----~------~----~------~--~---
