On Fri, 2006-08-04 at 13:36 +0800, Russell Keith-Magee wrote: > > On 8/4/06, Malcolm Tredinnick <[EMAIL PROTECTED]> wrote:
[...] > Related note that just occured to me: is there any intention to extend > query terms with this attribute-based inheritance syntax? i.e., is > something like: > > Place.objects.filter(restaurant__chef_name='Bork') > > going to be possible? And if so, what about: > > Place.objects.filter(Q(restaurant__chef_name='Bork') | > Q(baseballfield__home_team_name='Red Sox')) > > Any comments? I hate it (sorry). You can do it anyway with itertools.chain (except for ordering) and one day we might even get QuerySet unions between disparate tables implemented and it will be transparent then, too. For now it's just model abuse. I'm -1 on this until somebody can convince me it's actually useful and common. Next time I'm picking two Place types that have absolutely nothing in common so that you can't twist my examples into cases like this. Restaurants and SmallCometsInTheOortCloud, for example. I'm making this too easy for you. [...] > I feel I can live without anything resembling narrow() -- or C > ++'s > dynamic_cast, for those more familiar with that language -- > because I'm > not convinced there is an important use-case. However, if we > leave it > out, it does makes accessing the beer_price attribute, > wherever it may > live a little harder. It's also dangerous for me to be > projecting my > usages onto the world wide group of developers. I have some > experience, > but not *that* much. So, you probably have a point. > > Other than toy cases, I don't actually have a strong use case for this > kind of situation; however, I won't presume to represent the world > community of developers out there. I would only offer that the > existence of CORBA's narrow() is proof of the potential for a need (my > god... I'm defending the design decisions of the OMG... time to kill > myself... :-) I don't actually hate CORBA as much as the typical developer in the street. I kind of like programming with it sometimes; when it works, it's beautiful. So feel free to make the positive comparisons. However, I think the difference between CORBA's narrow() and our situation is that casting is a language feature in many of the language bindings that CORBA initially supported and is a necessity when you don't have duck typing in the language. It feels un-Pythonic and since we've already backed away from true duck typing, I would feel more comfortable being explicit about that. Anyway, I think we're in agreement that we can punt this for now and get the 90% case working first. OK, I think you and I are at least somewhat in agreement. Thanks, 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 -~----------~----~----~----~------~----~------~--~---
