oggie rob wrote:
> I would still avoid pluralization, if that was implied. Also you would
> need to add "count", "values", "bulk" etc but that seems natural enough
> from your suggestion (e.g. reporter.articles.count)
I would imagine that count could be done using __len__ on the list
proxy. Ie you would do :
len(reporters.articles)
This is certainly more pythonic. Yes, the implication was that the other
methods would be used like this as well.
> So by implication you could filter on the reporter object also? e.g.
> reporter.filter(first_name__startswith="John").order_by("last_name")
I don't really know what that would do, as the reporter is already an
instance. Was that not clear? The 'filter' thing is really to express
that you *already* have a 'collection', and you are filtering it by some
criteria.
> I have to say, though, this just seems like another way to "paint the
> bike shed".
I really have never understood this criticism. It makes about as much
sense to me as "Syntax doesn't matter", and it can effectively be used
to dismiss anything without actually addressing it at all.
My impression is that Django is *all about* doing things the right way.
The 'bikeshed' rubbish seems to say that every way of doing things is
equivalent, so we may as well do whatever is easiest.
This stuff *does* matter. Convenience and familiarity are the aim.
* the entire point of an ORM is to make working with a database more
like working with normal OO code
* this is far more 'normal' in the python world than methods magically
appearing in objects. The fields are descriptors (which are a standard
python feature) rather than disappearing from the class. The descriptors
that appear in the related class are a bit of residual magic, but I
think it is pretty useful. The other alternative is to force an
'endpoint' descriptor to be declared in the related to class, or added
to it later. This is another possibility... (explicit is better than
implicit etc.)
>Perhaps we should look at this by saying first "What is
> missing from our current implementation?" or "What is difficult?" The
> first few parts of the removing magic wiki make sense - adding
> properties, allowing for easier overloading of model behaviour, etc.
> Much of the syntax discussions that have been occurring since then have
> not deliberately solved many problems (except perhaps readability).
>
> If we want to really criticize the query syntax, we should start with
> these issues:
> 1) Limited join capabilities
> 2) Complicated "or" syntax
> 3) Limited aggregate functions
>
This makes about as much sense as "The police shouldn't fine me for
speeding when they could be out catching murderers." That we have other
features required doesn't mean we are not allowed to think about this one.
This feature is not about the query syntax as a whole. It is about
making ForeignKeys act 'normally' - ie as a collection.
