Last argument, I promise. Here's my version of your summary:
1. We have a connection object that represents a database. 2. From the Fields associated with this connection, Queries are produced with Field's overloaded operators. Queries can also be produced from combination of other Queries with the & | and ~ operators of Query itself. Certain options can be specified with Query methods. 3. Once we have a Query representing a set of JOINS and predicates, actual database operations are performed by invoking a Query's methods, .select(), .delete(), etc. > From the standpoint of the API, it doesn't really > matter that the query > becomes a Query object internally -- you just need to > know the query > syntax, and you pass your query syntax to the db object to > define your > records. > Maybe it's better to think about it from the perspective of using the API rather than worrying about the internal implementation. The existence of Query and Set objects are not a hidden implementation details. For example, if the user is unaware of the presence of Query objects, db(db.mytable.id == 3) shouldn't make any sense, as db.mytable.id == 3 should return a boolean. How could passing a boolean to db() possibly encode the information that makes up a query? Learners should not be given the impression that 'DAL syntax' is anything but just Python code. These are Python expressions that produce Python objects, not special cases. A Query is not syntax, it is an object that can be assigned to variables and passed around. Web2py, aside from its views, doesn't add any language on top of Python, and this is an important virtue. If learners take away the lesson that query expressions are a magic special case in Python itself, web2py is doing a disservice to those students. Removing Set would make the syntax slightly cleaner, but that's not the important point: the comprehensible mental model of the objects is more important than the syntax.
