On 1/27/06, Robert Wittams <[EMAIL PROTECTED]> wrote: > > Russell Keith-Magee wrote: > > On 1/27/06, Robert Wittams <[EMAIL PROTECTED]> wrote: > > It wasn't an attempt to be confusing. > > The intent does not change the effect.
Steady on soldier. Just because I disagree with you doesn't _necessarily_ mean I'm an idiot. :-) > > 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. ... which is what I proposed in the first place. I'm starting to get the feeling that we're talking at crossed purposes here. And I think I know why. The problem is I've been thinking of Article.objects() where the return value is an object representing an instance of a _query_, which can be modified, executed, reset, cached, or whatever. You, on the other hand, are looking at Article.objects being as a higher order representation of the underlying _set_. In your context, I'll agree that what I've been proposing doesn't make much sense, because there _is_ only one higher order representation of the underlying data. If you need to filter, you have a different set. Your version doesn't need Article.objects.all(), because Article.objects _is_ all. The only problem here is concurrency, which, as you rightly pointed out, is pretty close to a non-issue. >From my context, Article.objects() constructs a basic query that knows how to return all object instances of type Article, which can then be filtered to produce more complex query objects. The idea that there is a single basic query which everyone should use doesn't really make much sense - each query you want to make is unique, so it should have its own cache/state/etc. Half the confusion lies in the fact that my approach _could_ use your syntax, and vice versa, but on both counts, it wouldn't make much sense to do so, because of the way each solution represents the underlying problem. The rest of the confusion (at least on my part) stems is that there are a lot of references in this thread and the wiki to Article.objects being the Manager, with all()/filter() etc being used to get sets from the Manager; as a result, my mental picture of the Manager isn't one of a higher order set, it is one of managing SQL composition and a connection to a database. If you need to call objects.all(), then 'objects' by itself doesn't really represent anything other than a namespace for functionality. Does this sound like I have a better understanding of your position now? Does it clarify mine at all (not that you necessarily agree, but at least see where I'm coming from)? > > Consider Python dictionaries. If you have a dictionary, you call: > > This seems to have almost no relevance, and is incorrect, to boot. OK - the list/iterator confusion was a bit of a brainfart on my part, brought on by a long day and a late night in my part of the world. However, I would still argue that dicts _do_ use the items() notation, and consistency with the mother language is as least as important as exploiting the niftyness that is properties. Russ Magee %-)
