On Sep 15, 2007, at 5:10 PM, Ryan wrote:
> > And whatever happened to the nice select_by Query method where I could > mix filter-type criterion arguments and filter_by-type keyword > arguments in one call. *That* was readable to me, and very usable in > a pythonic way. What's wrong with having one filter method that does > everything? we do still have some of the *args **kwargs thing going on with the newer ORM clause constructs like has() and any(), since thats a lot easier than adding has()/has_by(), any()/any_by(), etc. But generally, with the generative API each method just does one small thing, this is mostly for the purposes of clear documentation. Flags, switches, and especially *args tend to be confusing to people, and its easier to understand diferent behaviors as grouped into distinct methods. its not impossible that filter() will again expand into allowing filter(*whereclauses, **kwargclauses)...but i dont want to rush into that. people especially get confused saying things like filter(somekeyword>5) and then getting a "no such name 'somekeyword'" python error, for example (i.e. clauseelements and keyword args start to get blurred together). before we had the generative, having distinct methods like this was not feasable...we had select(), select_by(), get_by(), selectfirst_by (), selectone_by(), etc...it was a disaster. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
