[Django] #32706: Ambiguity around field choices in the Model Field section

[Django]

#32706: Ambiguity around field choices in the Model Field section
------------------------------------------------+------------------------
Reporter: logankilpatrick | Owner: nobody
Type: Cleanup/optimization | Status: new
Component: Documentation | Version: 3.2
Severity: Normal | Keywords:
Triage Stage: Unreviewed | Has patch: 0
Needs documentation: 0 | Needs tests: 0
Patch needs improvement: 0 | Easy pickings: 0
UI/UX: 0 |
------------------------------------------------+------------------------
I am reading here:
https://docs.djangoproject.com/en/3.2/ref/models/fields/#django.db.models.Field.choices
about field choices. The docs remark that:

> "Generally, it’s best to define choices inside a model class, and to
define a suitably-named constant for each value:"

Why is this? Looking at the code, it is not abundantly clear to me as a
developer why this is the case. I think folks would benefit from a
sentence or two of commentary as to why this approach is generally better.

--
Ticket URL: <https://code.djangoproject.com/ticket/32706>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

[Django]

#32706: Ambiguity around field choices in the Model Field section

-------------------------------------+-------------------------------------
Reporter: Logan Kilpatrick | Owner: nobody
Type: | Status: closed
Cleanup/optimization |
Component: Documentation | Version: 3.2
Severity: Normal | Resolution: invalid

Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0

-------------------------------------+-------------------------------------
Changes (by Mariusz Felisiak):

* status: new => closed
* resolution: => invalid

Comment:

This is briefly explained in the same paragraph, just below the example:

> Though you can define a choices list outside of a model class and then
refer to it, defining the choices and names for each choice inside the
model class** keeps all of that information with the class that uses it,
and helps reference the choices** (e.g, Student.SOPHOMORE will work
anywhere that the Student model has been imported).

I think it's sufficient.

--
Ticket URL: <https://code.djangoproject.com/ticket/32706#comment:1>