First thoughts: subjectively, I'm not sure it'd be any prettier than what we have now. I'm also wary of overloading the concepts of the standard Python operators when whet we're really doing is translating to SQL operations -- sooner or later, there's going to be an impedance mismatch.
I'm also not a fan of the fact that, while claiming to make the end-user syntax less arcane, it would make the under-the-hood implementation *considerably* more arcane. On 2/9/07, David Abrahams <[EMAIL PROTECTED]> wrote: > Like I said, you can preserve backward compatibility. I'm also not sure this point came across quite as well as it should have: we did a massive ground-up rewrite of most of this stuff last year, and there were major, in-depth discussions about it. The lookup syntax we have now as a result of that is the lookup syntax we've promised to keep until Django 1.0, so unless someone demonstrates a literally earth-shaking enhancement, I think it's best to keep this API stable and concentrate on all the other bits which need work before the 1.0 release. > It didn't, and doesn't, work for me. Let me repeat and clarify the > reasons to add this extension: We did read it the first time ;) Unfortunately, no API will ever work for everyone -- it's the old "you can't please all of the people all of the time" problem. Sooner or later we have to accept that and leave well enough alone -- the DB lookup syntax doesn't seem to generate a whole lot of complaints or strange errors (as opposed to other things which most certainly do), so again I don't think there's enough justification to divert the necessary development resources into building yet another query layer when we've already got one that's guaranteed stable until 1.0 > From my point of view the gain in expressiveness is 100% worth it and > if I have to do any more serious model manipulation with Django and > it's not implemented yet, I'll do it myself. Expressive interfaces > lead to code that is more often correct the first time and easier to > read and maintain. I'm not sure how typing "<=" instead of "lte" is inherently more expressive... the self-declared most expressive language on the planet uses 'eq' as an equality operator, after all ;) And again, while not trying to bash on this, I think all you've demonstrated is a subjective gain for your use, and unfortunately that's not enough to re-open a stable API and start rewriting it all again -- this subjective gain for you would come at a high cost to Django in terms of the time and effort which would have to be directed into building out this new API, testing it, verifying it doesn't break anything, etc. > which is nearly as expressive. However, it is not as easy for such an > extension to give good error messages, so there are reasons to build > the functionality into the django core. Getting good error messages is a goal I'd be happy to help out with, but we don't need to rewrite the entire query system to do that -- the one we have right now is perfectly amenable to better error messages for end users. So again, I don't see enough of a gain to justify re-opening the database API. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
