On Apr 11, 11:55 pm, Michael Bayer <[EMAIL PROTECTED]> wrote: > 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...)
Because that is not valid SQL. AFAIK the only database that implements it is Sqlite and there it behaves exactly as expr != expr. It's quite probable that users will try to use empty .in_(). The options are: a) immediately raise an error + errors are easy(er) to find - invalidates sqlite behaviour b) produce IN () SQL + 1:1 mapping between python and sql - most databases will give obscure errors, possibly far away from source of error - different behaviour between databases c) do a natural extension of SQL IN syntax + makes user code simpler in non negligible amount of cases + behaves the same in all databases - some one could possibly expect different semantics Did I miss anything? --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
