On Oct 27, 5:55 pm, Jacob Kaplan-Moss <[email protected]> wrote: > On Wed, Oct 27, 2010 at 4:32 PM, Adrian Holovaty <[email protected]> wrote: > > I'm inclined to say we do the former -- restore the "ne" lookup type > > -- because it's a quick fix, and ask somebody to write up a patch for > > the latter. Does anybody have strong opinions against this? If not, I > > can restore the "ne" lookup type. > > Sounds like a good plan to me (especially making simple excludes faster). > > However, just for the record I think the reason we decided to remove > __ne is the first place was that its existence introduces a weird > inconsistency with regard to other lookup types. That is, if there's a > "ne" why isn't there a "nstartswith" or "nrange" or ... ? I think down > that path lies madness so I'm +0 on bringing back "ne" with the > proviso that we agree it's not the first step down a slippery slope > towards "nistartswith" and friends.
I know it's been a little while since I've made any major ORM contributions, but I'd say -0 on __ne, and +1 on making exclude generate better code. Django's worked far too hard on making things consistent as possible to let like this slip by just because we don't want to muddy our hands with a little harder work in the exclude() code. So many other tickets have been stuck in DDN/Accepted forever because the area of code is harder to review, it's not like it's an unknown state in the project. :) I'd even be willing to throw my hat in the ring to contribute towards an .exclude()-based solution if someone else doesn't step forward, but I know I won't be touching it until a few days pass. George -- 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.
