On Tue, 2006-10-10 at 04:06 -0700, Andrew Durdin wrote: > Looking at models.Manager, I noticed that for convenience it implements > many of the public methods of QuerySet, delegating the calls to its > query set. This obviously allows for more convenient behaviour, such > as writing MyModel.objects.filter(whatever) instead of > MyModel.objects.all().filter(whatever). > > However, I constantly trip over the fact that it doesn't implement > __iter__, as it seems natural to me to do for(obj in MyModel.objects). > Is there a particular reason for not implementing it? I can > understand that implementing __len__ and __getitem__ would encourage > inefficient code (due to the results not being cached), but is there > any such problem with implementing __iter__?
I'm somewhere between -0 and -1 on this. I could live with it, but it's inconsistent. The consistent design idea at work here is that a manager provides those methods that return a Queryset object. That is why we have .all() in the first place: it provides a way to convert from a manager object to a Queryset without applying any filters or restrictions at all to the default. Overloading __iter__ as you propose would break the theme a little bit. Now we would have a method that treats a manager like a Queryset, rather than returning a Queryset. Cheers, Malcolm --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
