"James Bennett" <[EMAIL PROTECTED]> writes: > First thoughts: subjectively, I'm not sure it'd be any prettier than > what we have now.
Can't argue with your subjective opinion. But I suggest you ask some newbies what they think. Also, "prettiness" is not really one of my goals, though I believe that generally comes along with expressiveness. > 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. Just like there's an impedance mismatch when Python using mathematical operators? What it's "really doing" is translating to bytecode representations of operations on machine internals. ;-) This sort of overloading makes some people uneasy, I know. I have a lot of experience with it, so am very familiar with both its benefits and limitations. It is true that you can't make everything transparent. For example, Python doesn't let you overload 'and' and 'or', so you need to do something else for those. However, what you end up doing for 'and and 'or' should be no worse than what you have now (after all, what you have now will work) > 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. I *seriously* doubt that. This feature is really simple to implement. Maybe I'll have to code it to prove that, but from the number of "I'm not a fan of..." responses I'm seeing here, I doubt that knowing it's simple would make much difference to any of the people who've responded. > 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. I understand that. > 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. I can appreciate that; I certainly didn't intend to suggest this was a "must have before 1.0" feature. [I'm responsible for getting a "must have before 1.0" feature into an ISO standard when the standard was already late and supposed to be closed to large changes, which never could have happened without appreciating the pressure the committee was under already. So believe me, I understand just what you are going through. It's not a struggle I care to repeat, either.] >> 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 ;) I wasn't just repeating myself. I added some material I thought would help people to better understand my position. > 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. Of course not. But not all qualities of an API are matters of personal preference or opinion. > 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 If that's the case, I agree. >> 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... Simple: it uses an existing notation, in the usual way, for an concept with which the user is already familiar. What you have done with 'xxx__yyy__gte=zzz' is invent a new domain-specific language for expressing predicates on Python objects (that's the high-level view that Django mostly appears to trying to supply) or, if you insist, doing database queries (that's the low-level view). The closer a domain-specific syntax comes to directly representing the concepts the user is manipulating in ways already familiar to the user, the more expressive it is. Both the high-level syntax and the low-level syntax use '>=' and not 'gte' to represent the concept, so I don't see any grounds for a claim that 'gte' is as expressive. > the self-declared most expressive language on the planet > uses 'eq' as an equality operator, after all ;) I suppose you mean lisp? Yeah, I never understood that claim. Too much syntactic regularity hurts expressiveness. > And again, while not trying to bash on this, I think all you've > demonstrated is a subjective gain for your use, That depends on the criteria used by this group to judge the quality of an API. I have laid out some objective criteria for judging the quality of a proposed API. I understand your criteria for judging the feasibility of immediately adopting my proposal, but not your criteria for judging its quality. > 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. Sure; I guess I'll build my layer on top of django in that case. Trying to take the temperature here: is there any sympathy here for the idea of adding it to contrib/, or is the whole idea simply anathema to this group? -- Dave Abrahams Boost Consulting www.boost-consulting.com --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
