Russell Keith-Magee wrote: > 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.
The intent does not change the effect. > It was an attempt to overcome a > problem with the Article.objects notation - namely, when is a query > executed When the results are needed? This is the entire basis of lazy evaluation. > and how do you reset it? I think this is a legitimate need, and one that can be simply supported with a clear_cache() method on QuerySet or whatever. > 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. This seems to have almost no relevance, and is incorrect, to boot. The thing returned is a list, not an iterator. This is a historical accident - if dictionaries were being defined now, it would be a set IMO. And I think you will find that properties and descriptors were not a feature of python when the interface of dictionaries was defined. I really see no reason why the second form of items wouldn't be used nowadays. If it were an iterator - you would still have no point. The cache makes no difference as to the *result* of operations, only to the *speed*. This is entirely different to the state changes in an iterator, which affect the result of the operations on the iterator. > 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? Cache is generally not considered to be state in the sense that you are using it. Eg in systems with const-ness present, caches are generally marked mutable. They *do not change the results of operations, only the efficiency*. Obviously there is a caveat in here about concurrent changes and cache consistency. I think most people are able to handle that. ( In the vast majority of cases by ignoring it because their whole business transaction is contained in one database transaction.) Robert
