Russ, It seems that no one else has any thoughts about this, so its just you and me.
First I note that I agree with you about count. I am taking that out. Next, I disagree about "average". Using the abbreviated SQLish name for all of the functions except one is bad. Either all of the names should be expanded or none. I prefer none since the non-standard SQL aggregate functions must match the SQL provided name precisely. Might as well make the standard function names do the same. The get_aggregate() function is really just the shared code behind sum(), min(), max(), stddev() and so forth. Arguably it could replaced by get_aggregates() (or whatever better name you might suggest), but then it will have a lot of extra setup and teardown code that is unecessary for the simple cases. Perhaps it should be _aggregate () to discourage end user use, but there are cases where I would want to use it. Hmmm. I will admit that using kwargs is more in line with the rest of Django, but I really dislike the thought that the mixmaster approach that you sketched out would be the only interface. I prefer a design that handles the simplest 80% of the calls trivially with the knowledge that the other 20% can be accomplished by dropping down to SQL (which, after all, is how I do the aggregate functions today.) Once we have a good 80/20 design, then a "kitchen sink" approach would be fun to explore and your suggestions are a good starting point. Finally, I agree that the name get_aggregate(s) kinda sux but I still haven't come up with anything better. Rock --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
