Over the past few months we've had a few back-and-forth tugs in the ticket tracker, and a couple of commits, related to the choice list for ``django.contrib.localflavor.us.forms.USStateField.``
Relevant background: * First, ticket #8425 asked for several choices to be removed, on grounds that they are now sovereign nations and not US territories or protectorates (resolution: the choices were removed): http://code.djangoproject.com/ticket/8425 * Then, ticket #9022 asked for US armed forces postal codes to be supported (resolution: wontfix): http://code.djangoproject.com/ticket/9022 So it seems there's some tension as to what, exactly, "USStateField" should do, and it seems there are a few options we could go with here: 1. Support only the fifty entities which are states of the US, and nothing else. This would make it a true "US state field", but would be unacceptable since this would exclude the District of Columbia (which is, famously, not a state) and so make quite a lot of people very unhappy. 2. Support the fifty states and the District of Columbia, and nothing else. This would technically add something that's not really a "US state", but I think most people would forgive us for it, and this is a bit more acceptable since it covers all common US destinations, for things like order forms which need addresses filled in. 3. Support all 50 US states, the District of Columbia, US overseas territories/protectorates/dependencies, and US armed forces postal codes. This would move further from just being "US state" field, but would cover a much wider range of "US" addresses. 4. Support the full list of locations/codes supported by the US postal service[1]. This includes several places which are sovereign nations, but which have specialized treaties or other agreements with the US (often the result of former trust territory status) and so are supported by the US postal service as "US" addresses. Personally I lean toward option 4. For a ``localflavor`` module, I think we really ought to rely on appropriate local authority whenever available, and in this case the US postal service is the appropriate authority for what constitutes a "US" address. One alternative, of course, would be to provide a number of separate fields -- one for "US states + DC", one for "US territories and protectorates", one for "US armed forces postal codes", etc. -- but given that the utility of a ``localflavor`` field like this mostly comes from having a *single* field that can cover addresses for a given locale, I'd be rather averse to it. Also, from a backwards-compatibility perspective, the ``USStateField`` in current trunk is a functionality regression for anyone relying on the ``USStateField`` from Django 1.0.x, and that's also something I'd prefer to avoid. Does anyone have strong feelings on this one way or another? With 1.1 looming I'd like to get this resolved and have a consensus view we can point folks to if there are further concerns about it. [1] http://www.usps.com/ncsc/lookups/abbreviations.html#states -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
