On 1/27/06, Robert Wittams <[EMAIL PROTECTED]> wrote: > > > On the class itself, Article.objects(), Article.values(), > > Article.in_bulk() become factory methods for producing Query objects > > which, when iterated, provide objects of the expected type (instances, > > dictionaries, etc). > > I've got to say, this is absolutely horrible and non-obvious. API design > should not be an exercise in how clever or confusing you should be - it > should be non-surprising. Article.objects acting as a set of Articles is > non-surprising. Article.objects.filter(whatever="fish") returning a new > filtered set is non surprising.
It wasn't an attempt to be confusing. It was an attempt to overcome a problem with the Article.objects notation - namely, when is a query executed, and how do you reset it? And I don't grant that Article.objects acting as a set is _completely_ non-surprising. Consider Python dictionaries. If you have a dictionary, you call: for key, value in my_dict.items(): ... _not_ for key, value in my_dict.items:... Why? Because my_dict.items looks like it's an attribute of my_dict - which it isn't - its an iterator: a stateful entity unto itself, so it is produced using a factory method on the dictionary. Queries are even more stateful than iterators, because they can be cached and reused, so they have the need to be both reset and re-executed over the database. How does this cache/reuse match the use expectations of a set as a standalone object? Russ Magee %-)
