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

On Tue, May 21, 2013 at 10:45 AM, Anssi Kääriäinen wrote: > I just pushed the patch to master. I didn't do anything to the API in > the latest pull. No only=True or .only(), and earliest() and latest() > still exist. I didn't feel like bikeshedding this issue any more. >

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

I just pushed the patch to master. I didn't do anything to the API in the latest pull. No only=True or .only(), and earliest() and latest() still exist. I didn't feel like bikeshedding this issue any more. I am happy that we now have some way to get single object from a queryset without using

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

Querysets definitely support indexing. Alex On Thu, May 16, 2013 at 2:51 PM, Alex Ogier wrote: > QuerySets don't support indexing. I'm not entirely sure why, but I > think the reason is to encourage more efficient database usage, since > naive usage of indexing would

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

QuerySets don't support indexing. I'm not entirely sure why, but I think the reason is to encourage more efficient database usage, since naive usage of indexing would lead to many repeated LIMIT 1 OFFSET N type queries. Forcing people to slice first encourages them to think about exactly how many

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

Let me clarify that I would expect both qs[:1][0] and qs[0] to raise IndexError if there were no results. On Thu, May 16, 2013 at 11:05 AM, Lee Trout wrote: > That's what I thought- But why not just qs[0]? > > Doesn't qs[:1] and qs[0] both cause a LIMIT 1 on the query? It

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

That's what I thought- But why not just qs[0]? Doesn't qs[:1] and qs[0] both cause a LIMIT 1 on the query? It seems that the [:1] is unnecessary. I would expect both to raise IndexError. On Wed, May 15, 2013 at 11:39 PM, Alex Ogier wrote: > Significantly better. The

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

Only is a different purpose than first, and as such it would make sense to me if it was a separate method. First has some implication that there may be second, third as well. It comes down to taste, but I think my buds would prefer a separate method. Ryan — Sent from Mailbox for iPhone On

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

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

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

Significantly better. The latter method loads every single model in the queryset into Python, potentially the whole database! On May 15, 2013 9:24 PM, "Lee Trout" wrote: > Is qs[:1][0] better form than list(qs)[0]? > > > On Wed, May 15, 2013 at 7:48 AM, Selwin Ong

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

Is qs[:1][0] better form than list(qs)[0]? On Wed, May 15, 2013 at 7:48 AM, 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

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

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,

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

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

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

Hi Selwin, 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. Wim On Sunday, 12 May 2013 06:55:04 UTC+2, Selwin Ong

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

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

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

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

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

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()

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

On 28 helmi, 01:34, 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

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

+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

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

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

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

+1 for first and last -- 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

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

> +1 for the first syntax. The others are duplicating functionality > that is already present via more aptly named methods. The first > syntax is also more consistent with other ORMs. Seconded. Seems much more obvious, simple and explicit than the other options to me. On Thursday, 28

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

On 02/27/2013 05:34 PM, 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

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

Oopsie: On Thursday 28 February 2013, Shai Berger wrote: > > Note that with this suggestion: > > qset.filter(a=b).first(c) > > is not equivalent to > > qset.order_by(c).filter(a=b) > That should have read qset.order_by(c).first(a=b) Shai. -- You received this message

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

On Thursday 28 February 2013, Aymeric Augustin wrote: > > I would support renaming them to first / last through a deprecation path. > The new aliases would be available immediately, the old ones would be > removed in two versions. > +1 > And while we're there, I suggest to rely on the existing

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

On 27 févr. 2013, at 23:34, Wim Feijen wrote: > Therefore, my proposal is, if we are going to implement the earliest and > latest method, we should definitely rename them to: first and latest. I believe that latest() was introduced with dates in mind, and then earliest()