Apologies for dragging this out. I don't mean to be combative, but... @pbreit It's weird if you're told OR if you think about it (especially if you aren't already very fluent in Python). If no one tells you, and if you don't think about it, it's probably fine. Also, the query already encapsulates the connection (Queries come from Fields which belong to Tables which belong to connections), so Set doesn't add that information either.
@Anthony Yes, keeping ignore_common_filters and similar future options in the query is much preferable to adding it to .select() et. al., so my first solution is the way to go. >> Something like: >> (db.mytable.id == 3).ignore_common_filters().select() > A bit ugly, and gets worse if we add more arguments in the future. Say in our API that we have a Cat type with some uncommon options for users to set. Which is the better approach for setting these options? A) add optional argument(s) to the constructor. B) add method(s) to modify the object state. C) add properties to assign. D) encapsulate the options in a wrapper class Feline. A), obviously, is the normal solution, but we can't do that with Query because we normally produce Query objects from overloaded operators of Field. Going with solution D) over B) or C) is a very odd thing to do. If D) served some other purpose, it might begin to make sense, but as I've already argued, it doesn't. (I suppose I should be thankful web2py didn't solve the problem with metaclasses :P)
