> > 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
signature.asc
Description: Digital signature
