Re: A.objects.getdefault

[Selwin Ong]

Hi Anssi,

Shouldn't first() and last() raise an exception if no ordering is 
specified? This keeps it consistent with latest() which requires the user 
to explicitly specify what field it wants to use as ordering.

Also, like you mentioned, IMHO these APIs are too similar (first, earliest, 
last and latest) in name, yet the usage is completely different, with 
latest() expecting a field name, the other filter args. What I also don't 
like is that the filter_args expected by last() and first() are:
1. Doesn't allow exclude arguments
2. We already have .filter() method which does the same thing (filters a 
queryset with passed kwargs)

So if I may suggest, I think a better option would be to change the methods 
first() and last() to behave more like latest(), but they should return 
None when the query returns no result. Example usage:

User.objects.exclude(a=b).filter(c=d).first('id') # Returns None if there's 
no match

 

user = User.objects.exclude(a=b).filter(c=d).last('id')
if user:
   # do things...


If last() and first() are introduced, perhaps we can also deprecate 
latest() in the future because they're very similar.

What do you guys think?

Best,
Selwin

On Sunday, January 20, 2013 1:51:27 PM UTC+7, Anssi Kääriäinen wrote:
>
> On 10 tammi, 09:27, Wim Feijen  wrote: 
> > Hi, 
> > 
> > Ticket 19326 has been marked as ready for check-in for some time. Can 
> > some-one have a look at it? 
> > 
> >  https://code.djangoproject.com/ticket/19326 
> > 
> > Thanks, 
> > 
> > Wim 
>
> I did some more polish to the patch. There is now also .last() method, 
> and if there is no ordering in the queryset, then it will be 
> automatically ordered by the primary key. 
>
> I didn't commit the patch yet, as I wonder if there will be confusion 
> about .latest(by_field), .last(filter_args). earliest(by_field) 
> and .first(filter_args)? 
>
> Currently, the usage is this: 
> a = 
> Article.objects.order_by('headline').first(pub_date__year=2005) 
> which will return first article by headline if any found or None if no 
> match. .last() will just change the ordering by first 
> calling .reverse() on the qs. 
>
> The patch is 100% ready for commit as far as I am concerned (cursory 
> check of the changes doesn't hurt, of course). So, if one of the BDFLs 
> sees the API as fine just go and commit the patch. 
>
> Patch available from 
> https://github.com/akaariai/django/compare/ticket_19326. 
>
>  - Anssi 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To view this discussion on the web visit 
https://groups.google.com/d/msg/django-developers/-/ovi4mYStQHYJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Re: A.objects.getdefault

[Selwin Ong]

Hi Wim,

I think there's a slight misunderstanding here. I completely agree with you 
that .first() and .last() should return None if there's no matching row :). 
The syntax I proposed:

User.objects.exclude(a=b).filter(c=d).first('id')  # Returns None if 
there's no matching row
User.objects.order_by('id').exclude(a=b).filter(c=d).first()  # Does 
the same thing as above

Best,
Selwin


On Wednesday, January 23, 2013 6:03:22 AM UTC+7, Wim Feijen wrote:
>
> Hi Selwin and Anssi,
>
> Anssi, thanks for improving the patch and getting it ready for commit! 
>
> Selwin, you are right that .filter() and .first() are very similar. 
> Rationale for .first() is to get rid of the pattern 
> try: 
> instance = ModelX.objects.get 
> except ObjectDoesNotExist:
> instance = None
> , which is a very common pattern so an exception seems out of place. Using 
> filter to get the first result or none would still require three lines. 
> Other alternative patterns are in this thread.
>
> For me, example use cases would be Address.objects.first() which would 
> return the first address in a list, when browsing through all addresses in 
> detail view, or page.music_files.first() where we just have one music file 
> per page or none. MusicFile.objects.first(page=page) should work too.
>
> Indeed, .earliest('timestamp') could be expressed as 
> .order_by('timestamp').first() , and latest similarly. In my opinion these 
> are consistent with .filter() and .get().
>
> Default ordering by id if no order is specified is the same behaviour as 
> in the admin, so I would argue not to raise an exception when no ordering 
> is specified, but to keep it like it is and order by id. Thanks for adding 
> that Anssi!
>
> Looking forward to other input,
>
> Best regards,
>
> Wim
>
>
> On Sunday, 20 January 2013 12:18:22 UTC+1, Selwin Ong wrote:
>>
>> Hi Anssi,
>>
>> Shouldn't first() and last() raise an exception if no ordering is 
>> specified? This keeps it consistent with latest() which requires the user 
>> to explicitly specify what field it wants to use as ordering.
>>
>> Also, like you mentioned, IMHO these APIs are too similar (first, 
>> earliest, last and latest) in name, yet the usage is completely different, 
>> with latest() expecting a field name, the other filter args. What I also 
>> don't like is that the filter_args expected by last() and first() are:
>> 1. Doesn't allow exclude arguments
>> 2. We already have .filter() method which does the same thing (filters a 
>> queryset with passed kwargs)
>>
>> So if I may suggest, I think a better option would be to change the 
>> methods first() and last() to behave more like latest(), but they should 
>> return None when the query returns no result. Example usage:
>>
>> User.objects.exclude(a=b).filter(c=d).first('id') # Returns None if 
>> there's no match
>>
>>  
>>
>> user = User.objects.exclude(a=b).filter(c=d).last('id')
>> if user:
>># do things...
>>
>>
>> If last() and first() are introduced, perhaps we can also deprecate 
>> latest() in the future because they're very similar.
>>
>> What do you guys think?
>>
>> Best,
>> Selwin
>>
>> On Sunday, January 20, 2013 1:51:27 PM UTC+7, Anssi Kääriäinen wrote:
>>>
>>> On 10 tammi, 09:27, Wim Feijen  wrote: 
>>> > Hi, 
>>> > 
>>> > Ticket 19326 has been marked as ready for check-in for some time. Can 
>>> > some-one have a look at it? 
>>> > 
>>> >  https://code.djangoproject.com/ticket/19326 
>>> > 
>>> > Thanks, 
>>> > 
>>> > Wim 
>>>
>>> I did some more polish to the patch. There is now also .last() method, 
>>> and if there is no ordering in the queryset, then it will be 
>>> automatically ordered by the primary key. 
>>>
>>> I didn't commit the patch yet, as I wonder if there will be confusion 
>>> about .latest(by_field), .last(filter_args). earliest(by_field) 
>>> and .first(filter_args)? 
>>>
>>> Currently, the usage is this: 
>>> a = 
>>> Article.objects.order_by('headline').first(pub_date__year=2005) 
>>> which will return first article by headline if any found or None if no 
>>> match. .last() will just change the ordering by first 
>>> calling .reverse() on the qs. 
>>>
>>> The patch is 100% ready for commit as far as I am concerned (cursory 
>>> check of the changes doesn't hurt, of course). So, if one of the BDFLs 
>>> sees the API as fine just go and commit the patch. 
>>>
>>> Patch available from 
>>> https://github.com/akaariai/django/compare/ticket_19326. 
>>>
>>>  - Anssi 
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@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.

Re: first() and last(), earliest() and latest()

[Selwin Ong]

+1 for the first syntax too :)

-- 
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.

Re: first() and last(), earliest() and latest()

[Selwin Ong]

Hi everyone,

I submitted a pull request implementing "first()" and "last()" here: 
 https://github.com/django/django/pull/1054

Comments welcome!

Best,
Selwin

On Thursday, February 28, 2013 5:34:16 AM UTC+7, 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.
>  
> 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.

Re: first() and last(), earliest() and latest()

[Selwin Ong]

Hi everyone,

I opened a new pull request implementing Shai's suggestions (I didn't 
overwrite the current branch so we can still compare the two 
implementations if needed).

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".

Thoughts?

The new pull request is here: https://github.com/django/django/pull/1056

Best,
Selwin

On Sunday, May 12, 2013 4:23:33 AM UTC+7, Shai Berger wrote:
>
> Hi Selwin, 
>
> On Saturday 11 May 2013, Selwin Ong wrote: 
> > Hi everyone, 
> > 
> > I submitted a pull request implementing "first()" and "last()" here: 
> >  https://github.com/django/django/pull/1054 
> > 
> > Comments welcome! 
> > 
> You implemented the "order_by" parameter as taking only one field name; 
> this is 
> inconsistent with the way ordering is done elsewhere  -- both the queryset 
> order_by() method, and the model meta ordering option, take a list of 
> field 
> names, each optionally prefixed by "-". 
>
> While I can see reason in going for a simpler implementation, I think it 
> is 
> much preferable to have a consistent API; and even if the simpler 
> implementation is preferred, you should take care of a more friendly error 
> message for someone who would call qset.first("a","b") or even 
> qset.last("-a") 
> [the latter may seem to make no sense -- "if that's what you want, call 
> qset.first('a')" -- but may reasonably arise in situations where the 
> ordering 
> field is received as an argument]. 
>
> Shai. 
>

-- 
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.

Re: first() and last(), earliest() and latest()

[Selwin Ong]

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 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.

Re: first() and last(), earliest() and latest()

[Selwin Ong]

Hi Shai,

We can add args and kwargs later when it's actually needed, it's not needed 
right now and it' cleaner, I think.

As for "only=True", these methods are meant to replace "latest()". If someone 
ones to ensure that the queryset returns only one object,  I dont think 
"Queryset.get()" is going anywhere soon so they should use that. Besides, 
"first()" and "last()" don't really make sense if you expect a queryset to only 
return a single object - ordering doesn't matter.

That's just what I think though.

Best,
Selwin

-- 
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.