So if I understand correctly, you want something that returns 0-or-1 objects, without having to do try/except? (Or alternately, try: qs[:1][0] except IndexError.)
First of all, I don't understand why first/last are the names you've chosen. This isn't about getting the first object or the last object. It's about getting first/last or None. That behavior is inconsistent with the way that Django's ORM works. (Though granted, it wouldn't be the only internal inconsistency.) A name like get_or_none() would make more sense to me, but apparently that was vetoed in the previous thread. Second, I don't understand what you expect to gain from adding these methods. Yes, I know you save a few lines of code. If it doesn't matter whether you get an object or not, you save three lines. If you have to take different paths, you only save one line. Essentially you're replacing this: try: obj = Model.instance.order_by(...)[:1][0] except IndexError: # Do something else: # Do something else With this: obj = Model.instance.order_by(...).first() if obj is None: # Do something else: # Do something else The gains don't seem to justify the means. Third, this seems to be about replacing latest/earliest. Personally, I don't have much use for either method, since they can be replaced with the first snippet above without any trouble. If anything, I'd rather see latest/earliest removed from the API than add new methods that do essentially the same thing. What I might see being useful would be a method to reverse the ordering of a queryset - which it turns out already exists.<https://docs.djangoproject.com/en/dev/ref/models/querysets/#django.db.models.query.QuerySet.reverse> Fourth, the methods proposed don't seem to do anything beyond act as shortcuts. In contrast, get_or_create (which on the surface is a similar shortcut) also adds protection against database inconsistencies by manually handling transactions. On Wednesday, February 27, 2013 5:34:16 PM UTC-5, Wim Feijen wrote: > > Hi all, > > We struggled to get a proper definition for a first() and last() method > vs. earliest() and latest() . I'd like to make one proposal. After that, I > really like your opinion on which syntax you prefer. > > First, let me give you a lenghty introduction. We discussed several use > cases on this mailing > list<https://groups.google.com/forum/?fromgroups=#!searchin/django-developers/get_default/django-developers/3RwDxWKPZ_A/mPtAlQ2b0DwJ>. > > Then, I realized that: > > .filter(last_name__startswith='b').order_by('last_name').first() > is an acceptable compromise for me to use in stead of: > .first(last_name__startswith='b').order_by('last_name') > > Last weekend Aymeric explained to me that earliest can actually accomplish > the same: > .filter(last_name__startswith='b').earliest('last_name') > > Then, I find "earliest" an inappropriate name, because it does not > describe functioning well. > > Therefore, my proposal is, if we are going to implement the earliest and > latest method, we should definitely rename them to: first and latest. > > After that, there is only one question left: > > Which style do you prefer? > > .filter(last_name__startswith='b').order_by('last_name').first() # > clear and long > .first(last_name__startswith='b').order_by('last_name') # first method > has filter syntax. > .filter(last_name__startswith='b').first('last_name') # first method has > order_by syntax. > > So, what do you think? > > Best regards, > > Wim > -- 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 django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
