>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 = (
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 li
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"
> 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, bu
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 reall
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 clo
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
--~--~---
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
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 Profil
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 stat
10 matches
Mail list logo
