Russell Keith-Magee wrote:
> I have a need - or, at least, larger plans for a need.
>
> Short version - don't just think about instances of Q() itself. You can also
> use any objects descendent from, or objects that meet the Q() intereface.
> This allows the end user to define queries that Djang
On 1/30/06, Luke Plant <[EMAIL PROTECTED]> wrote:
Yeah, I think you're right, I'm just aware that other people might beusing the Q() syntax already and have some use cases for it that I'munaware of. I haven't used it myself, and working on the setsthemselves seems fine for me.
I have a need - or,
On Monday 30 January 2006 18:56, Luke Plant wrote:
> Actually, Q()s are immutable, so doing a deepcopy on their account
> was a complete mistake on my part. You don't have to copy them at
> all, which would make them rather nice to use performance-wise.
In which case, and assuming there aren't o
On Monday 30 January 2006 16:11, Adrian Holovaty wrote:
> ... I prefer avoiding copy.deepcopy() --
> which had been necessary in QuerySet._clone() due to the fact that we
> were using Q() instances. That meant each call to _clone() (for
> filter(), order_by(), etc.) was doing deepcopy(), which m
On 1/30/06, Luke Plant <[EMAIL PROTECTED]> wrote:
> One thing - should _clone() actually do call
> 'self.__class__()' (or something like that), rather than QuerySet()?
> Otherwise you lose any subclass behaviour, which I don't think is
> desirable.
Good call -- yes, it should. Of course, if self.
Adrian wrote:
> It seemed a bit YAGNI to me, and I prefer avoiding copy.deepcopy() --
> which had been necessary in QuerySet._clone() due to the fact that we
> were using Q() instances. That meant each call to _clone() (for
> filter(), order_by(), etc.) was doing deepcopy(), which made me a bit
>
On 1/30/06, Luke Plant <[EMAIL PROTECTED]> wrote:
> In the new descriptor syntax, are we going to allow Q() objects as
> positional arguments to the filter() method (and others)?
> [...]
> I mention this because I see you've changed core_filters back to a
> dictionary of lookup arguments, Adrian,
Robert Wittams wrote:
> Couldn't you just pass a model class or manager into your function that
> generates the appropriate queryset from that? Seems like an esoteric
> need anyway.
Yeah, I think you're right, I'm just aware that other people might be
using the Q() syntax already and have some u
Luke Plant wrote:
> In the new descriptor syntax, are we going to allow Q() objects as
> positional arguments to the filter() method (and others)? They seem
> like they could be a useful way of creating queries, although there is
> some duplication now that you can combine QuerySets directly. Ho
In the new descriptor syntax, are we going to allow Q() objects as
positional arguments to the filter() method (and others)? They seem
like they could be a useful way of creating queries, although there is
some duplication now that you can combine QuerySets directly. However,
passing QuerySets a
10 matches
Mail list logo
