Re: Choice lookups
>It'd be nice if we could do this:
>Profile.objects.filter(favorite_skit__display='parrot')
As Rob already hints, this gets a bit more complicated when
internationalization comes in the picture...
The choices are then defined as lazy_translations rather than strings
literals:
CHOICES = (
(1, _('parrot') ),
(2, _('argument') ),
)
Views will display the translated value.
Querying for the raw value is the only way the query is made "language-
neutral".
Using the display value makes it dependent on the language, which
doesnt seem a clean solution looking at it from a ORM layer
perspective.
The syntax used by James looks like the correct solution to your
readability concern to me.
My 2 cents,
Johan
--~--~-~--~~~---~--~~
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?hl=en
-~--~~~~--~~--~--~---
Re: Choice lookups
I prefer to store the actual value in database in many cases instead of an
assigned numerical or other representation so I find myself doing this:
color_choices = [(c,c) for c in ["red", "blue", "green"]]
It's not a difficult work-around but I would love to see Django accept a 1
dimensional list of values for choices as an alternative to a set of tuples.
Justin
On 10/31/07, ludvig.ericson <[EMAIL PROTECTED]> wrote:
>
>
> On Oct 30, 6:26 pm, "Jeremy Dunck" <[EMAIL PROTECTED]> wrote:
> > It's always bugged me a little that choice lookups are based on the raw
> value.
> Agreed, but bloating the API doesn't solve that.
>
> Oh and a tip:
>
> FOO_CHOICES = enumerate(("foo", "bar"))
>
> Throw on a tuple() if you want to use the in operator or so. (Above is
> equal to ((0, 'foo'), (1, 'bar')))
>
> --
> Ludvig Ericson
>
>
> >
>
--~--~-~--~~~---~--~~
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?hl=en
-~--~~~~--~~--~--~---
Re: Choice lookups
On Oct 30, 6:26 pm, "Jeremy Dunck" <[EMAIL PROTECTED]> wrote:
> It's always bugged me a little that choice lookups are based on the raw value.
Agreed, but bloating the API doesn't solve that.
Oh and a tip:
FOO_CHOICES = enumerate(("foo", "bar"))
Throw on a tuple() if you want to use the in operator or so. (Above is
equal to ((0, 'foo'), (1, 'bar')))
--
Ludvig Ericson
--~--~-~--~~~---~--~~
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?hl=en
-~--~~~~--~~--~--~---
Re: Choice lookups
> On 10/30/07, Marty Alchin <[EMAIL PROTECTED]> wrote:
> > James, I think you've managed to hit (what I'd consider) the perfect
> > stride there. You have to import Entry anyway, so by making your
> > constants class attributes, you avoid the extra import requirement.
>
> It's not quite an enum, but it's close enough for my taste.
It works great for me too.
Though on further reflection, I think Jeremy's asking for something
> that's legitimately useful: it'd be nice to have some way to accept
> the human-readable value (say, in a URL) and use it to do the lookup
> with that.
Are there i18n issues that pop up here? what is the reverse of {0:_("my
value")}?
Rob :)
--~--~-~--~~~---~--~~
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?hl=en
-~--~~~~--~~--~--~---
Re: Choice lookups
On 10/30/07, James Bennett <[EMAIL PROTECTED]> wrote: > Though on further reflection, I think Jeremy's asking for something > that's legitimately useful: it'd be nice to have some way to accept > the human-readable value (say, in a URL) and use it to do the lookup > with that. Hrm, I hadn't really considered URLs, to be honest. I actually have a situation that could indeed benefit from that. /contact/ /contact/president/ /contact/treasurer/ etc... -Gul --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: Choice lookups
On 10/30/07, Marty Alchin <[EMAIL PROTECTED]> wrote: > James, I think you've managed to hit (what I'd consider) the perfect > stride there. You have to import Entry anyway, so by making your > constants class attributes, you avoid the extra import requirement. It's not quite an enum, but it's close enough for my taste. Though on further reflection, I think Jeremy's asking for something that's legitimately useful: it'd be nice to have some way to accept the human-readable value (say, in a URL) and use it to do the lookup with that. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: Choice lookups
James, I think you've managed to hit (what I'd consider) the perfect stride there. You have to import Entry anyway, so by making your constants class attributes, you avoid the extra import requirement. I hereby retract my +0 in favor of a -0. Either way, I'm still stuck at "meh." -Gul --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: Choice lookups
Wow, that's an interesting idea. I don't think I'd use it very often, but I definitely like the idea. It would add a little bit of overhead beyond the existing, but that's only when people actually use it, and I expect that won't be terribly often. This seems like the kind of thing that would be most useful in a urlconf, specifying base querysets for use with generic views. These would only get called once when the module is loaded, so the impact would be minimal. Views would likely be doing lookups based on user input, rather than programmer input, so those probably wouldn't use it much. The only other performance hit I can think of would be in models that use it to reference subsets of related models. And in those cases, if it's really a problem, it's still easy and readable to just expect programmers to scroll up to the CHOICES assignment and see what the number refers to. Of course, I tend to assign those numbers to constants, which I then reference, but you're right that it still requires an input in order to use that outside of the file where it's defined. All in all, I kinda like it, but I doubt I'll use it. +0 I suppose. One thing I'd add is a check that the value is in fact present in the display list before running the query. For instance, if 'parrot' wasn't actually a valid option, the QuerySet could figure that out and return an EmptyQuerySet instead, without ever touching the database (since it wouldn't even know what to look for anyway). It's either that or throw an error. I'd hate to see that behavior undefined. -Gul --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Re: Choice lookups
On 10/30/07, Jeremy Dunck <[EMAIL PROTECTED]> wrote: > It's always bugged me a little that choice lookups are based on the raw value. > > Example for discussion: > CHOICES = ( >(1, 'parrot'), >(2, 'argument'), > ) > > class Profile(models.Model): > user = FK(User) > favorite_skit = IntegerField(choices=CHOICES) > > > In staticly-typed languages, and paraphrasing a bit, lookups like this > are based on enums. Hm. Actually, what I've typically done is something like this (ripped from my blog code): class Entry(models.Model): LIVE_STATUS = 1 DRAFT_STATUS = 2 STATUS_CHOICES = ( (LIVE_STATUS, 'Live'), (DRAFT_STATUS, 'Draft') ) status = models.IntegerField(choices=STATUS_CHOICES) # ...etc. Which then leads fairly naturally into lookups like Entry.objects.filter(status__exact=Entry.LIVE_STATUS) It's a bit more typing, but I like the way it encapsulates the choices into the model class, and it leads to much more readable lookups (without a need for magic numbers). -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
Choice lookups
It's always bugged me a little that choice lookups are based on the raw value. Example for discussion: CHOICES = ( (1, 'parrot'), (2, 'argument'), ) class Profile(models.Model): user = FK(User) favorite_skit = IntegerField(choices=CHOICES) In staticly-typed languages, and paraphrasing a bit, lookups like this are based on enums. Querying for parrot lovers: Profile.objects.filter(favorite_skit=1) which is kind of unreadable. It'd be nice if we could do this: Profile.objects.filter(favorite_skit__display='parrot') That is, introduce a new __display lookup type which accepts a string and tries to get the raw value based on the choices kwarg on that field. (A little utility could be added for choice reversal: REV_CHOICES = dict((v,k) for (k,v) in CHOICES) Profile.objects.filter(favorite_skit=REV_CHOICES['parrot']) but that's a sideline; you still have to do the import and it's a bit verbose, especially if you consider likely namespace collisions. ) The only complaint I can see for this is that some people may be using different raw values to map to the same display value, but the new __display lookup type would just be another way; querying with raw values would still work. Thoughts? --~--~-~--~~~---~--~~ 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?hl=en -~--~~~~--~~--~--~---
