On Wed, Jun 4, 2008 at 2:23 AM, Nicolas Lara <[EMAIL PROTECTED]> wrote:
>
> On Mon, Jun 2, 2008 at 8:53 AM, Russell Keith-Magee
> <[EMAIL PROTECTED]> wrote:
>> for values in Author.objects.values('name','age'):
>> for name,age in values.items():
>> print name, age
>>
>> Simple use cases like this need to remain simple.
>
> And they will. The user would only need to worry about the mixed
> output when he is actually requesting the mixed output.
My point is that the user shouldn't ever need to worry. A list that
contains multiple versions of similar things is easy to process by
iteration. A list that contains "similar things except for the one the
isn't" is not as trivial to process.
> I do think it is better to some extent to have the same type of
> objects in a dict, but I also think in this case it wouldn't be a
> problem since the the mixed output would be explicitly requested by
> the user. We could even add a method to ValuesQuerySet to 'clean' the
> output avoiding the queryset from being returned (in case you received
> the queryset from some another module and want to handle it without
> knowing what's inside). we could even add a special method to return
> the values with the group queryset and have the default iterator
> exclude the groups.
Bleh. Adding methods to clean up after the mess made by a different
feature? -1 to that.
> The problem I see with the tuple approach is that, well, you have a
> tuple instead of a dict. So values would in some cases return a list
> of dicts and in others a list of tuples, which I found more
> inconsistent than mixed types inside a dict. Also you would need to
> handle the tuple just to get to your data.
Well, you're going to have to handle the data no matter what format
the output takes. The upside of my approach is that you can assign the
different return types to different variables, and handle them
differently:
for values, members in Author.objects.values('age','name',groups=True):
...
whereas your approach requires some manipulation of the return type to
extract the data that doesn't match everything else before you can do
any sort of iteration over the returned value data.
As for having a single method with two different return types
depending on context - there are already examples of Django APIs that
do this. For example, values_list returns a list of tuples, unless you
provide the flat=True argument, in which case you get a list of
values.
You are explicitly asking for different output, so the fact that
different output happens shouldn't be entirely surprising. And
remember - In your propsal, you're getting back different output as
well - one version has the magic 'groups' member, one doesn't.
However, you can't tell that it's different output until you iterate
over the result you get back from the call.
Yours,
Russ Magee %-)
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
