On Sep 14, 2007, at 3:52 PM, Rick Morrison wrote:
> I think it might be more historical than anything else. Back when > what is now filter() was a single argument to the select() call, on > the SQL-API side, and there couldn't take any additional arguments, > as the select() call was already pretty heavy with keyword > arguments and it was easy to get things mixed up. That and the > historical SelectResults() extension on which this whole API is > modeled, only took a single expression in its filter() method. > > Now that filter() is it's own construct, I can't see any reason why > it couldn't take a list of expressions that were assumed to be > AND'ed. Well, any good reason except that it's also pretty easy, > -- and arguably more readable -- to just chain multiple .filter() > calls using the generative style: > > .filter(and-expr-1).filter(and-expr-2) I've raised the notion of allowing filter() to take *criterion but theres been some debate about this. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
