#35766 closed Bug (fixed)
Choice iterator breaks when using slices
Reported by: | David | Owned by: | Sarah Boyce |
---|---|---|---|
Component: | Database layer (models, ORM) | Version: | 5.0 |
Severity: | Normal | Keywords: | |
Cc: | Natalia Bidart, Nick Pope | Triage Stage: | Ready for checkin |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description (last modified by )
Currently the choice-iterator classes introduced in https://code.djangoproject.com/ticket/24561 are designed to work with index-based access.
class MyModel(models.Model): field = models.IntegerField(choices=lambda: range(10)) the_field = MyModel._meta.get_field("field") the_field.choices[2] #> 3
Since choices has been out for long time accepting there are libraries in which the field.choices
attribute was used as it it was a tuple/list, which can be accessed also with slicing syntax (see sphinxcontrib-django ), this now raises an error:
the_field.choices[:2] --------------------------------------------------------------------------- TypeError Traceback (most recent call last) Cell In[13], line 1 ----> 1 the_field.choices[:2] File /opt/venv/lib/python3.10/site-packages/django/utils/choices.py:24, in BaseChoiceIterator.__getitem__(self, index) 23 def __getitem__(self, index): ---> 24 if index < 0: 25 # Suboptimally consume whole iterator to handle negative index. 26 return list(self)[index] 27 try: TypeError: '<' not supported between instances of 'slice' and 'int'
The __getitem__ states that the management of key type should be handled in the implementation.
It should be choosen if slices are going to be supported or if only integers are going to be supported by this class.
Change History (10)
comment:1 by , 2 months ago
Description: | modified (diff) |
---|
comment:2 by , 2 months ago
Cc: | added |
---|---|
Component: | Uncategorized → Database layer (models, ORM) |
Has patch: | set |
Owner: | set to |
Status: | new → assigned |
Triage Stage: | Unreviewed → Accepted |
Type: | Uncategorized → Bug |
follow-up: 6 comment:5 by , 2 months ago
Sarah, isn't this a regression in the last Django version that warrants a backport?
comment:6 by , 2 months ago
Replying to Claude Paroz:
Sarah, isn't this a regression in the last Django version that warrants a backport?
Hey Claude, thanks for keeping an eye on things!
But the feature was introduced in 5.0 so it does not qualify for a backport at this time.
comment:8 by , 2 months ago
Yes you're right - I missed this. I will create a release note a back port shortly
comment:10 by , 2 months ago
I still think that this does not qualify for a backport: 07fa79ef2bb3e8cace7bd87b292c6c85230eed05 was landed in main
right before the 5.0 beta release, that means during the 5.0 alpha-beta phase. Thus, it was backported to the stable/5.0.x
branch due to the "alpha" backporting policy. Therefore, this commit is really a "5.0 feature" and it's my understanding that this does not qualify for a 5.1 backport.
Thank you, replicated
I imagine we do want to support it (but I might be wrong) - made a small patch