Jacob Kaplan-Moss wrote:
>
> Hey folks --
>
I understand your point about changing code, it is a big irritation. I
was thinking that it *might* be possible to have something which
optionally adds back the current methods. API changes are always
annoying. Unfortunately back-compat is often even more annoying to maintain.
Re the hitting the database thing, I get your point. I'm not really sure
about that one. Personally, I consider every operation in a language
with customisable attribute access and operators to be a function call
anyway, so don't make an assumption about how it is going to work.
>
> Another thing to think about is that currently relation methods "make
> sense" when hit from a template::
>
> {{ reporter.name }} has {{ reporter.get_article_count }} articles.
>
> I agree that len(reporter.articles) is more pythonic, but at the same
> time it's not as accessible from the template.
I've got to admit, I wouldn't mind doing :
{{ reporter.name }} has {{ reporter.article_set|length}} articles.
In all honesty, I prefer this version.
This would make it a lot more consistent with non-django objects used in
templates.
> I also agree with Robert that if we use a descriptor is should be named
> in a way that doesn't need pluralization; that's currently how methods
> are named (get_article_list, get_article_count, etc.).
>
> I guess in essence it comes down to whether we'd rather be explicit
> (reporter.get_article_list()), or "pythonic" (reporter.article_list)...
I would think that the second version is "explicit" in another way: the
thing you are "getting" is just something you defined in the class. The
get_article_list is an implicitly defined method, which is kind of odd
if you think about it.
