Choice iterator breaks when using slices

[David]

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.

[Sarah Boyce]

Thank you, replicated
I imagine we do want to support it (but I might be wrong) - made a small patch

[Sarah Boyce]

PR received approval

[Sarah Boyce <42296566+sarahboyce@…>]

In ae1ee241:

Fixed #35766 -- Handled slices in BaseChoiceIterator.

[Claude Paroz]

Sarah, isn't this a regression in the last Django version that warrants a backport?

[Natalia Bidart]

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.

[Claude Paroz]

Isn't the related commit 07fa79ef2bb3e8cace7bd87b292c6c85230eed05 ?

[Sarah Boyce]

Yes you're right - I missed this. I will create a release note a back port shortly

[Sarah Boyce]

​PR - have some questions as to whether it is required for the backport

[Natalia Bidart]

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.