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

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 goi

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 lead to many repeated LIMI

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 r

Re: Proposal: Redefine specific {% block %} in an intermediate template

Any feedback on how I was thinking? Does it make sense? Based on the feedback so far I gather that changing the block tag is a bad idea. I'd love to continue working on this, because I've felt this need in lots of different projects. A new proposal could be in terms of a new pair of tags, mayb

Re: django and paramstyle: what's the actual story?

On Thursday 16 May 2013, VernonCole wrote: > I noticed in a recent post that there is an outstanding patch for Oracle > for support of 'named' paramstyle. > As the author of that patch, I should probably clarify that it is a "format" style -- %(name)s -- not a "named" -- :name -- style. AFAIK,

Questions about ticket #19431

Hi guys, Some months ago I submitted a pull request for the ticket #19431 . Even it's a really small thing, didn't get the time until now (DjangoCon, yay!) to go through last of Florian's reviews. How should I

Re: django and paramstyle: what's the actual story?

On 16 mai 2013, at 09:29, VernonCole wrote: > What is the feeling of this group? Should I maintain my activism that %s > 'format' paramstyle be maintained into the future? Or should I be helping > the django community to prepare for a new future where one must (or may?) > choose between a pa

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 seems that > the [:1]

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 latter method loads every

Re: Perception of attitude in tickets

On 16/05/13 13:29, Russell Keith-Magee wrote: > Patching Trac sounds like a really good idea to me. While I completely > appreciate the intent of these wiki messages, the way those messages are > "deployed" at the present strikes me as something that could easily be > interpreted as rude. I'd like

Re: Perception of attitude in tickets

I was going to mention this before, but wasn't sure how to word it. Russell has hit the spot though, giving the user a more personal experience, not just automated (or manual) copy-pasta. Cal On Thu, May 16, 2013 at 1:29 PM, Russell Keith-Magee < russ...@keith-magee.com> wrote: > > On Thu, May

Re: Perception of attitude in tickets

On Thu, May 16, 2013 at 7:16 PM, Luke Plant wrote: > On 15/05/13 19:36, ptone wrote: > > > I wonder if a slightly more concise version of this should be added to > > the triaging docs instead of a wiki page (fine place to draft it though). > > > > > https://docs.djangoproject.com/en/dev/internals

Re: Perception of attitude in tickets

On 15/05/13 19:36, ptone wrote: > I wonder if a slightly more concise version of this should be added to > the triaging docs instead of a wiki page (fine place to draft it though). > > https://docs.djangoproject.com/en/dev/internals/contributing/triaging-tickets/#closing-tickets > > I feel that

Re: Automatic deployment tool

Hi all, Some improvements have been made and documentation is coming. For the curious, here is a 5min screen recording of me using it on our deployment environment that I'll present this weekend on djangocon-europe. You can watch it here: https://vimeo.com/66302371 It shows: - The hierarchi

Re: django and paramstyle: what's the actual story?

As for the death of '%s' style -- yes please, with sprinkles on top. It is totally violating the principle of least astonishment as anyone will expect '%s' to expand to a parameter string; yet that's not what it does, it magically adds quotes and whatnot. The other two variants are widely u

Re: Anyone have ideas on #16550 - custom SQL before/after syncdb?

As a sidenote, there was a discussion about this on this mailing list a few months ago: https://groups.google.com/forum/#!searchin/django-developers/16550/django-developers/xN0aMzrmA1Y/KsrsEf7XOA8J -- You received this message because you are subscribed to the Google Groups "Django developers"

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 Thu

django and paramstyle: what's the actual story?

I noticed in a recent post that there is an outstanding patch for Oracle for support of 'named' paramstyle. I also found, during my morning's research on the question, that there has been at least one patch so that django will play nice with 'pyformat' paramstyle. I got involved with this enti

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