dj.choices 0.11.0

Filtering

The developer can specify all possible choices for future use and then filter out only the currently applicable values on choices creation:

>>> class Language(Choices):
...   _ = Choices.Choice
...
...   de = _("German")
...   en = _("English")
...   fr = _("French")
...   pl = _("Polish")
...
>>> Language()
[(1, u'German'), (2, u'English'), (3, u'French'), (4, u'Polish')]
>>> Language(filter=("en", "pl"))
[(2, u'English'), (4, u'Polish')]

This has the great advantage of keeping the IDs and sorting intact.

Custom item format

One can also change how the pairs are constructed by providing a factory function. For instance, to use the class of choices defined above for the LANGUAGES setting in settings.py, one could specify:

>>> Language(item=lambda choice: (choice.name, choice.raw))
[(u'de', 'German'), (u'en', 'English'), (u'fr', 'French'),
 (u'pl', 'Polish')]

Extra attributes on choices

Each choice can receive extra arguments using the extra() method:

>>> class Python(Choices):
...   _ = Choices.Choice
...
...   cpython = _("CPython").extra(language='C')
...   pypy = _("PyPy").extra(language='Python')
...   jython = _("Jython").extra(language='Java')
...   iron_python = _("IronPython").extra(language='C#')

This adds a language attribute to each choice so you can get it back like this:

>>> Python.jython.language
'Java'

This enables polymorphic attribute access later on when using models or forms. For instance, suppose you have a simple model like:

>>> class Library(models.Model):
...   name = models.CharField(max_length=100)
...   python_kind = models.IntegerField(choices=Python(), default=Python.cpython.id)

In that case to get the implementation language back you’d do:

>>> library = Library.objects.get(name='dj.choices')
>>> Python.from_id(library.python_kind).language
'C'

That frees your user code of any conditionals or dictionaries that depend on the state of the choices class. If you would add another choice to it, no user code needs to be changed to support it. This also supports the DRY principle because the choices class becomes the single place where configuration of that kind is held.

Extra attributes on choice groups

Unsurprisingly, choice groups can have extra attributes as well. They are then inherited by choices in such a group and can be overriden if necessary. For instance:

>>> class ProfileChange(Choices):
...   _ = Choices.Choice
...
...   USER = Choices.Group(0).extra(icon='bookkeeping.png', is_public=True)
...   email = _("e-mail").extra(is_public=False)
...   first_name = _("first name")
...   last_name = _("last name")
...
...   BASIC_INFO = Choices.Group(10).extra(icon='bookkeeping.png', is_public=True)
...   birth_date = _("birth date").extra(icon='calendar.png')
...   gender = _("gender").extra(icon='male_female.png')
...   country = _("country")
...   city = _("city")
...
...   CONTACT_INFO = Choices.Group(20).extra(icon='contactbook.png', is_public=False)
...   skype = _("Skype ID")
...   icq = _("ICQ number")
...   msn = _("MSN login")
...   xfire = _("X-Fire login")
...   irc = _("IRC info").extra(is_public=True)

In that case proper inheritance takes place:

>>> ProfileChange.first_name.is_public
True
>>> ProfileChange.email.is_public
False
>>> ProfileChange.country.icon
'bookkeeping.png'
>>> ProfileChange.birth_date.icon
'calendar.png'

0.11.0

• Drop compatibility for Django < 1.4 and Python 2.6

• Add support for Django 1.9 and 1.10 (use from_db_value instead of SubfieldBase)

• Add support for Python 3.5

0.10.0

• Works and tests run on Django 1.6 and Django 1.7; now tested with Python 3.4 as well

0.9.2

• Python 2.6 is now supported as well thanks to Carl van Tonder

0.9.1

• Long overdue Python 3 support (considered experimental)

0.9.0

• Choices are now int subclasses so you can use a choice directly instead of choice.id and int(choice) is always safe

• unicode(choice) is now equivalent to choice.desc

• Fixed get_FIELD_display() on models with ChoiceFields

0.8.6

• Values outside of defined choices for a ChoiceField now correctly display validation errors instead of throwing exceptions; fixes issue #2

• ChoiceField can have default=None

• Fixed regression from 0.8.5 where __gt(e) and __lt(e) couldn’t be used on ChoiceField lookups

• Minor refinements

0.8.5

• ChoiceField is now correctly South-migrable

• Models with ChoiceFields can now use __in, __range and __isnull lookups on them; fixes issue #1

0.8.4

• proper ChoiceField support if the underlying IntegerField returns a long instead of an int

• minor __unicode__ corrections for byte strings

0.8.3

• MANIFEST.in was previously missing which made the source distribution hard to install

0.8.2

• ChoiceField introduced

• extra attribute injection API is now public and documented

0.8.1

• old accessors temporarily restored for backward compatibility (undocumented and to be removed in 1.0)

• minor documentation fixes

0.8.0

• code separated from lck.django

• PEP8-fied the accessor APIs