On Tue, Oct 20, 2009 at 10:09 PM, Michael P. Jung <[email protected]> wrote: > > I'd like to propose a new field lookup __neq which could be used to > negate a single parameter. It is not ment to make exclude() obsolete, as > they both have a different scope: > > filter(x__neq=1, y__neq=2) would translate to "(x <> 1 AND y <> 2)" > while exclude(x=1, y=2) translates to "NOT (x = 1 AND y = 2)"
yes, but: exclude(x=1).exclude(y=2) translates to NOT (x=1) AND NOT (y=2) So, put me down as -1 on this. As a matter of historical note, once upon a time, Django _did_ have a __neq operator. It was removed in favour of the exclude() grouping. > So far I'v never come across a single use case, where I had to exclude() > based on more than one field, but I have several applications where I > perform more than one __isnull=False lookups. Since __isnull is ment to > be obsolete, according to Russ Magee, it'd be really ugly having to > rewrite these queryies to a chain of excludes. I didn't say they were obsolete - I said that they existed for historical reasons. I don't think there's been any formal decision to deprecate these operators. > Besides exclude(x=None).exclude(y=None).exclude(z=None) feels less > intuitive to me than filter(x__neq=None, y__neq=None, y__neq=None). Opinion noted, but I disagree :-) The way Django interprets filter() and exclude() groups is consistent across a number of uses, including logical structure and join reuse. Personally, I don't find it at all unusual that exclude(A, B) is different from exclude(A).exclude(B). Yours, Russ Magee %-) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
