class A(enum.Enum):
label = "label"
print("case A, builtin Enum type:", A.label)
class B(TextChoices):
LABEL = "label"
print("case B, TextChoices with a choice `LABEL`:", B.LABEL)
try:
class C(TextChoices):
label = "label"
except Exception as e:
print("case C, TextChoices with a choice `label`:", e)
try:
class D(IntegerChoices):
label = 0
except Exception as e:
print("case D, IntegerChoices with a choice `label`:", e)
}}}
output:
{{{
case A, builtin Enum type: A.label
case B, TextChoices with a choice `LABEL`: label
case C, TextChoices with a choice `label`: Cannot reassign members.
case D, IntegerChoices with a choice `label`: Cannot reassign members.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/32460>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
* owner: nobody => starryrbs
* status: new => assigned
Comment:
I checked the source code of django, in django.db.models.enums path:
{{{
cls.label = property(lambda self: cls._value2label_map_.get(self.value))
cls.do_not_call_in_templates = True
}}}
{{{label}}} and {{{do_not_call_in_templates}}} cannot be used as enum
keys.
We may need to add this to the Django document or change the label to
configurable.
I submitted a pull request to support this feature.
[https://github.com/django/django/pull/14020]
--
Ticket URL: <https://code.djangoproject.com/ticket/32460#comment:1>
* owner: starryrbs => Nick Pope
* has_patch: 0 => 1
* stage: Unreviewed => Accepted
Comment:
Hi. Thanks for the report.
So looking at this, I don't think that making it possible to customise the
`.label` property name is the right approach.
`Enum` doesn't have a problem providing `.name` or `.value` attributes on
the members while still allowing those names to be used as member names.
I have something sorted out that will fix this for `.label` and
`.do_not_call_in_templates` (although the latter is rather niche!)
This is also broken for `.names`, `.values`, `.labels`, and `.choices`.
These are, however, probably not fixable as they must exist on the top-
level class itself and not the members, so they would collide with the
member names. Perhaps this part of the problem can be addressed with some
documentation.
Alternate [https://github.com/django/django/pull/14022 PR].
--
Ticket URL: <https://code.djangoproject.com/ticket/32460#comment:2>
Comment (by elonzh):
Replying to [comment:2 Nick Pope]:
> Hi. Thanks for the report.
>
> So looking at this, I don't think that making it possible to customise
the `.label` property name is the right approach.
>
> `Enum` doesn't have a problem providing `.name` or `.value` attributes
on the members while still allowing those names to be used as member
names.
> I have something sorted out that will fix this for `.label` and
`.do_not_call_in_templates` (although the latter is rather niche!)
>
> This is also broken for `.names`, `.values`, `.labels`, and `.choices`.
These are, however, probably not fixable as they must exist on the top-
level class itself and not the members, so they would collide with the
member names. Perhaps this part of the problem can be addressed with some
documentation.
>
> Alternate [https://github.com/django/django/pull/14022 PR].
using methods to get such members? like `get_labels()`, these methods
introduce API changes but I think it's a clear solution?
--
Ticket URL: <https://code.djangoproject.com/ticket/32460#comment:3>
Comment (by Nick Pope):
Replying to [comment:3 elonzh]:
> using methods to get such members? like `get_labels()`, these methods
introduce API changes but I think it's a clear solution?
Every example in the [https://docs.python.org/3/library/enum.html enum]
documentation and the
[https://docs.djangoproject.com/en/3.1/ref/models/fields/#field-choices-
enum-types Field.choices] documentation uses the convention of uppercase
member names. Maybe I was naive to assume that people wouldn't use
lowercase member names.
While we could rename these, I'm not sure it is worth the change. We'd
need to deprecate first for a few releases. It will annoy lots of people
who will then have to update this for a small edge case. On top of that,
the names `get_labels`, etc. would also then not be allowed, merely
shifting the problem. At the end of the day, these choices helper classes
are not compulsory and, as documented, a sequence can be used.
--
Ticket URL: <https://code.djangoproject.com/ticket/32460#comment:4>
* stage: Accepted => Ready for checkin
--
Ticket URL: <https://code.djangoproject.com/ticket/32460#comment:5>
Comment (by Mariusz Felisiak <felisiak.mariusz@…>):
In [changeset:"41e39c41c9225bc3cbd5f333694e0a4d113136be" 41e39c41]:
{{{
#!CommitTicketReference repository=""
revision="41e39c41c9225bc3cbd5f333694e0a4d113136be"
Refs #32460 -- Doc'd and tested that property names of model choice enums
cannot be used as members.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/32460#comment:6>
* status: assigned => closed
* resolution: => fixed
Comment:
In [changeset:"a96c730431196b119559bbb18a0e85e6ee8b2597" a96c7304]:
{{{
#!CommitTicketReference repository=""
revision="a96c730431196b119559bbb18a0e85e6ee8b2597"
Fixed #32460 -- Allowed "label"/"do_not_call_in_templates" members in
model choice enums.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/32460#comment:7>