Re: Confusion around generic views queryset cloning.

On 22 July 2013 10:37, Loic Bistuer wrote: > 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. > No

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 wrot

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

Re: Confusion around generic views queryset cloning.

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 `_clone()` rather than `all()` and with #20625 on its way, I think it's useful to have a

Re: Confusion around generic views queryset cloning.

Can't we just use .all() in views instead of creating a new QuerySet method which does exactly the same thing? On Sun, Jul 21, 2013 at 12:34 PM, Loic Bistuer wrote: > My attempt with a public `QuerySet.clone()` method and docs for > `*ObjectMixin.queryset`: > > https://github.com/django/django/p

Re: Confusion around generic views queryset cloning.

My attempt with a public `QuerySet.clone()` method and docs for `*ObjectMixin.queryset`: https://github.com/django/django/pull/1384 Made a PR to facilitate review and discussion, feel free to close if you think it's the wrong approach. -- Loic -- You received this message because you are su

Re: Confusion around generic views queryset cloning.

Thanks both, the responses are very much appreciated. > It's the same issue as using mutable default arguments or attributes to a class. If someone is writing their own generic CBVs without understanding I don't see why the queryset case is any more problematic than having a class with an empty

Re: Confusion around generic views queryset cloning.

I don't think this should need documenting explicitly. It's the same issue as using mutable default arguments or attributes to a class. If someone is writing their own generic CBVs without understanding I don't see why the queryset case is any more problematic than having a class with an empty list

Re: Confusion around generic views queryset cloning.

Hi Tom, (You said in a follow-up this was intended for django-users, but personally I think it's on-topic for -developers, so I'm replying here.) On 07/11/2013 02:54 PM, Tom Christie wrote: > I've noted that the generic view implementations use the private > `_clone` method when returning the que

Re: Confusion around generic views queryset cloning.

My apologies, this was intended to be posted to the Django users group. On Thursday, 11 July 2013 21:54:25 UTC+1, Tom Christie wrote: > > I've noted that the generic view implementations use the private `_clone` > method when returning the queryset > attribute

Confusion around generic views queryset cloning.

I've noted that the generic view implementations use the private `_clone` method when returning the queryset attribute . Presumably the need for that is something to do with the potential for querysets to be cached