#34388: Added support for direct usage of Choices classes on model fields
-------------------------------------+-------------------------------------
Reporter: T. | Owner: nobody
Franzel |
Type: New | Status: new
feature |
Component: Database | Version: dev
layer (models, ORM) |
Severity: Normal | Keywords:
Triage Stage: | Has patch: 1
Unreviewed |
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
-------------------------------------+-------------------------------------
Hi,
I would like to propose a feature addition on how `Choices` are handled
when used on model fields. Currently, `Field.choices` only accepts
iterables. This has 2 shortcommings imho:
1. - Rejecting a `Choices` class as argument to `Field(choices=...)` seems
counter-intuitive. Providing the class directly currently results in a
`fields.E005` error.
- To make this more pythonic, the field should also accept the Choice
class directly and deal with the variation internally.
- I really can't come up with a scenario where a user would want a
different behavior or rather that a user would be surprised by the
implicit resolution.
2. By forcing the user to expand the `Choices` class manually, essentially
all meta information is lost. Downstream packages may benefit from this
lost information.
- Specifically, as maintainer of [https://github.com/tfranzel/drf-
spectacular drf-spectcular] (OpenAPI generator for DRF), I am interested
in the name of the choice set (e.g. Suit, Vehicle, Gender) and potentially
also the docstring. This would greatly improve OpenAPI generation of
choice sets and take out the unnecessary guesswork to find a proper name.
(And if anyone wonders, the model field name is not a good candidate for a
choice set name.)
This PR allows to use `Choices` classes directly as argument, while being
transparent. No behavioral changes otherwise.
I marked this as `dev`, but it would be awesome if it could still slip
into `4.2`. Not sure if the feature window is still open, but this is more
or less a trivial and backwards-compatible change with little risk. PR is
still missing some docs, which I will write if this is considered.
{{{ #!python
class Suit(models.IntegerChoices):
""" All possible card categories in a deck """
DIAMOND = 1, _("Diamond")
SPADE = 2, _("Spade")
HEART = 3, _("Heart")
CLUB = 4, _("Club")
class Choiceful(models.Model):
# CURRENTLY:
from_enum_old = models.IntegerField(choices=Suit.choices)
# NEW: raised an fields.E005 prior to proposed PR. Now, retains
reference
# to class and transparently resolves via implicit `.choices` call
from_new = models.IntegerField(choices=Suit)
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/34388>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/01070186b32643a5-b2a75bf4-2b18-42de-8fcd-6e65ad7cf25b-000000%40eu-central-1.amazonses.com.
