Re: Deprecate FCGI support in Django 1.7

On 23/07/13 02:07, Curtis Maloney wrote: Well, having started looking over the flup source, I can see a lot of useful code to crib, as well as a few critical path bits that can be optimised [without even reducing readability!] So, if you feel like helping out with django-fastcgi ... I'm happy

Re: Deprecate FCGI support in Django 1.7

Well, having started looking over the flup source, I can see a lot of useful code to crib, as well as a few critical path bits that can be optimised [without even reducing readability!] So, if you feel like helping out with django-fastcgi ... I'm happy for the help :) -- Curtis On 23 July

Re: Custom Chainable QuerySets (#20625)

On Jul 23, 2013, at 3:17 AM, Aymeric Augustin wrote: > Either way the factory should receive the QuerySet in argument as well as any > other parameters required to create the custom Manager appropriately. I missed the "other parameters required" part.

Re: Custom Chainable QuerySets (#20625)

I'm not a big fan of TIMTOWTDI so I don't think we should have both `Manager.from_queryset()` and `QuerySet.as_manager()`. The following commit moved all the logic that was on `QuerySet` to the `Manager` class and implemented the `from_queryset()` API:

Re: Custom Chainable QuerySets (#20625)

On 22 juil. 2013, at 17:31, Loic Bistuer wrote: > The goal is to make it painfully easy to get a `Manager` from a custom > `QuerySet` and for most cases, having the factory on `Manager` instead of > `QuerySet` results in a more verbose syntax and requires an

Re: Deprecate FCGI support in Django 1.7

On 22/07/13 10:00, Russell Keith-Magee wrote: The hope is to start accelerating the release cycle slightly; however, this also depends on someone actually doing the work :-) Sounds good. I'd love to start helping with Django myself but I feel a bit lost when it comes to useful things to do.

Re: Custom Chainable QuerySets (#20625)

I would like to point out that using both a custom `Manager` *and* a custom `QuerySet` is an edge case. After all, you can already do that if you want to. The goal is to make it painfully easy to get a `Manager` from a custom `QuerySet` and for most cases, having the factory on `Manager`

Re: Custom Chainable QuerySets (#20625)

On Monday 22 July 2013 13:25:38 Anssi Kääriäinen wrote: > On Monday, July 22, 2013 1:16:04 PM UTC+3, Loic Bistuer wrote: > > On Jul 22, 2013, at 4:38 PM, Chris Wilson > > > > > > wrote: > > > I think that's very true. How about this? > > > > > >> class

Re: #10284, #17988 -- should formset.save(commit=False) delete objects marked for deletion?

On 12 juil. 2013, at 22:47, Tim Graham wrote: > formset.save(commit=False) on ModelFormSets currently deletes any objects > marked for deletion which seems like a bug to me, since I wouldn't expect any > data changing operations when using commit=False. I put together a

Re: Custom Chainable QuerySets (#20625)

On 22 juil. 2013, at 12:16, Loic Bistuer wrote: > That was my original proposal; the first 20 comments on the ticket and one > nearly complete implementation are based on this idea. Oh, sorry. I dived into the pull request without reading the ticket first. I'm

Re: Custom Chainable QuerySets (#20625)

On Monday, July 22, 2013 1:16:04 PM UTC+3, Loic Bistuer wrote: > > On Jul 22, 2013, at 4:38 PM, Chris Wilson > wrote: > > > I think that's very true. How about this? > > > >> class MyQuerySet(models.QuerySet): > >> def published(self): > >>

Re: Custom Chainable QuerySets (#20625)

On Jul 22, 2013, at 4:38 PM, Chris Wilson wrote: > I think that's very true. How about this? > >> class MyQuerySet(models.QuerySet): >> def published(self): >> return self.filter(published_date__lte=now()) >> >> class MyModel(models.Model):

Re: Deprecate FCGI support in Django 1.7

> To anyone else reading this thread who is still wanting FastCGI I am willing > to help with a third party solution if something is going to come together. > Based on the normal Django release cycle I'd expect 1.7 to be out in either > Q4 this year or Q1 next year so something needs to be done

Re: Composite fields -- (ir)regular status report #3

On Mon, 22 Jul 2013, Michal Petrucha wrote: I have some awesome news today. At long last I managed to finally get the refactor of ForeignKey to pass the entire test suite. That is awesome news! Well done Michal! I am really looking forward to having this feature available in Django.

Re: Custom Chainable QuerySets (#20625)

The idea of `QuerySet .as_manager()` sounded sane to me at first—especially in the light of the failure of various other attempts—but it creates a circular dependency between `Manager` and `QuerySet`. Creating the `Manager` class now requires the `QuerySet` class, and `QuerySet` needs a

Re: Deprecate FCGI support in Django 1.7

On Mon, Jul 22, 2013 at 4:48 PM, Some Developer wrote: > On 22/07/13 05:47, Russell Keith-Magee wrote: > >> Based on the feedback from this thread (and the fact that multiple core >> devs, including a BDFL have weighed in), I think it's safe to say that >> the decision

Re: Deprecate FCGI support in Django 1.7

On 22/07/13 05:47, Russell Keith-Magee wrote: Based on the feedback from this thread (and the fact that multiple core devs, including a BDFL have weighed in), I think it's safe to say that the decision has been made. The only question at this point is how long it takes before someone commits the

Custom Chainable QuerySets (#20625)

Ticket #20625 deals with the problem of writing custom QuerySet methods. The problem is that one needs to write some boilerplate code to have methods available on both the Manager and the QuerySet. The ticket has a patch for having custom QuerySet methods automatically available on the model's

Re: Confusion around generic views queryset cloning.

I updated the PR to do away with the public `clone()` method. As long as we have a long-term goal for a `QuerySet.clone()` method, I'm happy. If we plan on changing the cloning behavior, now is effectively a bad time to introduce it. -- Loic On Jul 22, 2013, at 2:45 PM, Anssi Kääriäinen

Re: Confusion around generic views queryset cloning.

On Sunday, July 21, 2013 9:53:36 PM UTC+3, Loic Bistuer wrote: > > Explicit is better than implicit and `all()` is more a `Manager` concept > than a `QuerySet` one. > > IMO `QuerySet.all()` should only be used when API parity with `Manager` is > needed. > > Internally `QuerySet` uses