Jacob Kaplan-Moss wrote: > class Article: > writer = meta.ForeignKey(Reporter, related_name="articles") > sites = meta.ManyToManyField(Site) > > s = Site.objects.get(pk=1) > r = Reporter.objects.get(pk=1) > > s.article_set.all() > r.articles.all() > > That is, if ``related_name`` isn't given then ``OBJECT_set`` is used.
Given that this is identical to my original plan for descriptor fields ( don't randomly rename things, only make up names when no name is provided by the user), I'm all for this. Making <whatever>_set into religion was not the aim... > > That's kinda what I would expect. The only problem is that list() > doesn't actually return a list -- it returns a Query that can be > iterated over... Hm... > > OK, what about this: make ``objects`` callable:: > > Before After > > Article.objects.get_list() Article.objects() > Article.objects.get_list(**kw) Article.objects(**kw) > Article.objects.get_object(**kw) Article.objects.get(**kw) > Article.objects.get_values(**kw) Article.objects.values(**kw) > > That's more concise in the common case -- I'd guess that get_list() is > far and away the most common method used -- and it does away with the > filter/all distinction. > > Thoughts? I don't really like it. I much prefer the idea of the manager being something you can iterate over directly, and filter being a method to use when you want to filter it, that returns an object of the same type but just filtered down. Ie Article.objects is just a set that happens to be backed by the database, and just happens to be filterable. Seems pretty intuitive to me. No .all() or __call__ required. I don't think the same can be said for making random objects callable... I have no idea what this means, its just entirely arbitrary. Things should generally only pretend to be functions when that is their main purpose.
