#31261: Add support for defining models.Choices fields with dict, tuple, set and
list values.
-------------------------------------+-------------------------------------
     Reporter:  Tom Forbes           |                    Owner:  nobody
         Type:  New feature          |                   Status:  closed
    Component:  Database layer       |                  Version:  master
  (models, ORM)                      |
     Severity:  Normal               |               Resolution:  needsinfo
     Keywords:                       |             Triage Stage:
                                     |  Unreviewed
    Has patch:  0                    |      Needs documentation:  0
  Needs tests:  0                    |  Patch needs improvement:  0
Easy pickings:  0                    |                    UI/UX:  0
-------------------------------------+-------------------------------------

Comment (by Tom Forbes):

 I can construct a `Choices` object with mutable values, it fails if
 `.choices` is called on the object but otherwise it works fine.

 I've found that the current code checks if the value is a list or a tuple,
 so something like this is currently supported:

 {{{
 SOME_KEY = [1, "display value]
 }}}

 I can't find tests for this and didn't know this was possible, but this
 does make it quite hard to make work as described in the ticket
 description without a lot of magic.

 However what what about abandoning the idea of defining things using
 literals and use a special class:


 {{{
 class MoonMissions(models.IntegerChoices):
     ...
     SUCCESSFUL_MISSIONS = ChoiceSet(APOLLO_10, APOLLO_11)

     SUCCESS_GROUPING = DisplayGroup({
         "Failed": FAILED_MISSIONS,
         "Successful": SUCCESSFUL_MISSIONS
     })
 }}}

 From the point of view of the metaclass this makes things a _lot_ simpler,
 as you don't need to try and work out if the given value is an enum value,
 a value with a display.

 It's not as nice as using a literal but it does sidestep a lot of issues.
 Another thing that might be simpler to do with a class is "stitching up"
 the choice/group values. Ideally we'd want the values of
 `SUCCESSFUL_MISSIONS` to be an Enum object, not the primitive type (or the
 tuple type if it has a display value), so the code would have to update
 these classes after the enum is initialized and all enum members created,
 replacing the raw references with their corresponding Enum objects.

-- 
Ticket URL: <https://code.djangoproject.com/ticket/31261#comment:9>
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/061.4c04971d725e3f88dba0b5e54757d6b6%40djangoproject.com.

Reply via email to