On 1/28/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
> > My votes:
> >
> > 1. Model.objects
> > 2. instance.sites
> > 3. q.count()
> > 4. related_name: yes
+1 for 1,2,4.
On 3 I'm not completely convinced. I like the elegance/language symmetry of
len(Model.objects). I can see two possible objections with allowing it:
- Firstly, how does __len__ fit in with query execution? I would argue that
len(Model.objects) should effectively return len(list(Model.objects)).
This would mean that the cache would be fully populated as soon as you
call len(). This is less efficient if you don't intend to use the
contents of the object set, but 1) this strikes me as the edge case,
and 2) we could retain objects.count() call as a non-caching size
call.
- Secondly, the template language doesn't lend itself to making the
len(Model.objects) call. One solution here - modify the template
lookup order to add global functions taking a single parameter as one
of the lookup options: i.e., {{ object.attr }} will be evaluated as:
object[attr]
object.attr
object.attr()
attr(object)
I'm unsure of the exact order of precedence, though. Last resort seems
right to me.
The counterobjection to the template change is that as a result of the
choice of python keyword, {{ Model.objects.len }} isn't that intuitive
to template writers. Also, it could start to encourage people to start
using global functions as filter-like objects, which we probably don't
want to do.
Russ Magee %-)
