Is "accept a callable" the best solution for everywhere this problem occurs? For example, same thing was proposed in "FileField storage param should allow a callable" (#28184). It seems a bit odd to me that on the one hand we say that we need to track changes to all model field attributes, but then we avoid that by hiding changes behind a callable.
https://code.djangoproject.com/ticket/28184 On Thursday, January 11, 2018 at 7:55:50 PM UTC-5, Josh Smeaton wrote: > > https://code.djangoproject.com/ticket/22837 was closed as invalid. It > concerns itself with migrations being detected when model field choices > (which may be dynamic) change. The workaround suggested is to pass a > callable to choices with a link to > https://code.djangoproject.com/ticket/13181. However, that ticket only > concerns itself with FormField.choices accepting a callable. > > There are many times where dynamic choices causes unnecessary migrations > to be detected, sometimes in external apps: > > - pytz gains new timezone codes > - country codes are added or removed > - new states are added to an internal library > - settings determine the set of choices > > I would like to reconsider reopening > https://code.djangoproject.com/ticket/22837 with the goal of making > ModelField.choices accept a callable. There is sufficient frustration > within the community to warrant such a change I feel. > -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/ead9b0fa-0038-47cc-beaf-1c0f435fe09a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
