On 10/12/06, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote: > I agree the second two cases are bugs. I'm probably -0 on making > exact=None be the same as isnull=True, because it's a synonym for > something you can already do (we already have isnull). Still, I guess > it's a harmless change (which is why I'm not -1).
I agree that it duplicates functionality. Obviously, keeping __isnull around for legacy purposes doesn't harm anyone, so we might as well keep it around. However, I would argue that: 1) __isnull is a special case. Special cases bug me, as they usually indicate an inconsistency in usage somewhere (in this case, the inconsistency of using None as a query value) 2) Adding the extra logic throughout the Managers to handle unsaved objects strikes me as much more inelegant (and much more likely to get forgotten/unexpectedly broken) that the few lines that would be required to implement the fix at the query level. 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 -~----------~----~----~----~------~----~------~--~---
