2012/4/3 Łukasz Langa <luk...@langa.pl>:
> Explicit choice values::
>
>  GENDER_MALE = 0
>  GENDER_FEMALE = 1
>  GENDER_NOT_SPECIFIED = 2
>
>  GENDER_CHOICES = (
>      (GENDER_MALE, _('male')),
>      (GENDER_FEMALE, _('female')),
>      (GENDER_NOT_SPECIFIED, _('not specified')),
>  )
>
>  class User(models.Model):
>      gender = models.IntegerField(choices=GENDER_CHOICES,
>              default=GENDER_NOT_SPECIFIED)
>
>      def greet(self):
>          if self.gender == GENDER_MALE:
>              return 'Hi, boy.'
>          elif self.gender == GENDER_NOT_SPECIFIED:
>              return 'Hello, girl.'
>          else: return 'Hey there, user!'
>
> This is a saner way but starts getting overly verbose and redundant. You can
> improve encapsulation by moving the choices into the ``User`` class but that 
> on
> the other hand beats reusability.

I don't see the immediate need for Yet Another Sub-framework, as
described in this proposal. This is what I normally do, and it works
fine:

class User(models.Model):
    MALE = 0
    FEMALE = 1
    GENDERS = [(MALE, 'Male'), (FEMALE, 'Female')]
    gender = models.IntegerField(choices=GENDERS)

    def greet(self):
        return {MALE: 'Hi, boy', FEMALE: 'Hi, girl.'}[self.gender]

If people aren't understanding that, we should improve our documentation.

Also, the fact that we *don't* have a sub-framework for this lets
people do whatever they want -- including using the dj.choices module.
So I am -1 on including this in Django proper.

Adrian

-- 
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 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en.

Reply via email to