@Andrew: Thanks! That's precisely the missing piece from my code; if I get some time to put it all together, I think it'll be a full solution. My approach uses sets of arbitrary flag values rather than creating constants for flags, and it's implemented as a normal model field, which seems a little cleaner than introducing a new syntax.
@Craig: I never thought of just monkeypatching the necessary dictionaries to add new lookup types. You'd need to do it for all the DB backends, of course. And as with monkeypatching in general, it's not a real sustainable practice to go messing with global reference dicts; if it became common practice to do that for new field types you'd start getting name collisions pretty quickly. I think I'll probably continue to prefer the custom Q object. Carl --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com 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 -~----------~----~----~----~------~----~------~--~---
