Two notes:
1) I think it is better to leave the *args, **kw on the manager methods; since
they are just forwarding to the qset anyways, there's no harm in that, and it
makes them more "future proof" (i.e. you wouldn't need to change them next
time you change the interface of the qset methods).
Case in point:
2) I'd like to add an argument to the first() method, something like
def first(self, only=True):
Where the sense of only=True is that if there is more than one object to get,
that's an error (MultipleObjects, like in get).
As this feature was mainly designed to replace the anti-pattern,
try:
x = qset.get(...)
except DoesNotExist
x = None
I think the default for "only" should indeed be True. Other people may
disagree. I think without at least the ability to set only=True, this feature
is essentially broken -- since it is the equivalent of
try:
x = qset[0]
except IndexError
x = None
it encourages people to give up an integrity check.
My 2 cents,
Shai.
On Wednesday 15 May 2013, Selwin Ong wrote:
> I've updated the first() and last() to not accept any arguments. Please
> review it and let me know if there's anything else I need to change.
> Hopefully this can get merged in during the sprints and make it into 1.6
> :).
>
> The pull request is here: https://github.com/django/django/pull/1056
>
> Best,
> Selwin
>
> On Monday, May 13, 2013 8:12:35 PM UTC+7, Michal Petrucha wrote:
> > > > I initially modeled "first()" and "last()"'s behaviors to mimic
> > > > "latest()", but in this new pull request, you can pass multiple field
> >
> > names
> >
> > > > into "first()" and "last()" so it behaves like "order_by()". It's
> > > > more flexible and requires less typing, but I wonder if we should
> > > > just get
> >
> > rid
> >
> > > > of the optional field arguments and rely on "order_by" for ordering.
> >
> > "There
> >
> > > > should be one-- and preferably only one --obvious way to do it".
> > >
> > > Considering "There should be one-- and preferably only one --obvious
> > > way
> >
> > to
> >
> > > do it", I definitely prefer to rely on order_by to do the ordering, not
> >
> > on
> >
> > > first.
> > >
> > > .order_by('name').first()
> > >
> > > is clear and readable in my opinion.
> >
> > My thoughts exactly, we already have one method that does ordering, I
> > don't think it is necessary to make these methods incorporate that
> > functionality. If we did, we might argue that other QuerySet
> > operations could be supported as well and that would just result in a
> > bloated API. Especially if there's no performance gain (the QuerySet
> > would be cloned anyway), and it only saves a few lines of code.
> >
> > Also, skimming through this thread, I think there was a consensus on
> > first() and last() not taking any ordering arguments, i.e. the first
> >
> > proposed syntax:
> > .filter(last_name__startswith='b').order_by('last_name').first()
> >
> > Michal
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
