i vote no interpretation at all...if you want IN with one element, thats what youll get. no elements, ditto.
also the bind param + etc ticket is #476. its got svilens artwork attached to it which i'd like to refine into a patch + unit test (but without the vis4check module/visitor thing...too complex..would rather have it just take ClauseElements unconditionally for now). On Apr 11, 2007, at 4:58 PM, Rick Morrison wrote: > I think the singleton to equals is fine, but I'd be equally OK with > a "no surprises" policy. I think the empty-list optimization should > go, tho. > > > > On 4/11/07, Michael Bayer <[EMAIL PROTECTED]> wrote: > > > 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 -~----------~----~----~----~------~----~------~--~---
