On Sat, Aug 22, 2009 at 7:49 PM, Tim Chase<[email protected]> wrote: > > James Bennett wrote: >> The current proposal is for a "USPostalCodeField" which >> corresponds to the US Postal Service's list of postal codes: >> >> http://www.usps.com/ncsc/lookups/abbr_state.txt >> >> [snip] Based on the various arguments up to this point, it >> seems like no single field is going to make everybody happy,
Agreed that this particular argument is a recurring theme that we should address. > Internally, I've solved a similar "can't make everybody happy" > problem with a class factory function that takes the desired set > of defined data, depending on the project: Given that the number of options is constrained, a fully-fledged factory strikes me as overkill. Why not just booleans on the field itself? USStateField(lower_48=True, dc=True, non_contiguous=True, protectorates=False, military_drops=True) No need to deprecate anything - we can continue to ship USStateField as is, just with some extra options that have default boolean values set to reflect the currently enabled choices. Given that US postal codes seems like a particularly common request, there isn't much harm in including a a USPostalCodeField as a shortcut - it's just a subclass with all the options set True. Yours, Russ Magee %-) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
