+1! An added benefit that you didn't mention is easier maintenance -- each individual localflavor package could have its own maintainer(s), meaning they wouldn't have to get the attention of a core committer to get fixes in.
One question: would you be thinking of doing some sort of namespace package deal so that `django.contrib.localflavor.us.Whatever` continues to work with an externally-installed `django-localflavor-us` package, or is part of this requiring users to change imports? I have no real opinion either way -- that is, I'm asking, not telling </inside-joke>. Jacob On Thu, Aug 16, 2012 at 3:26 PM, Adrian Holovaty <adr...@holovaty.com> wrote: > I'd like to move all Django localflavor code into a separate package, > distributed separately from Django the framework. > > WHY? > > 1. We shouldn't be in the business of updating Romanian phone number > rules (e.g., https://github.com/django/django/pull/275). That doesn't > belong in a Web framework. > > 2. The localflavor code makes Django more bloated than it should be, > in terms of number of files (a concern with stuff like App Engine) and > download size (not a huge concern, but still worth improving). > > THE HISTORY > > On Feb. 14, 2007, I created django.contrib.localflavor because I felt > guilty we had USA-specific form fields. > https://github.com/django/django/commit/27b28616b405578d81fb8e6a4efdc73459c81a2b > > Nearly immediately, people saw this and started contributing form > fields and validation logic for their own countries / governments. It > was kind of amazing to watch all of the patches come in, and you could > feel the national pride from contributors all over the world. > > In retrospect, setting this expectation and allowing all of this code > into Django proper was a bad idea. We should have created an > infrastructure for a *separate* package (or packages) of > country-specific stuff, not shipping it with Django proper. > > PROPOSED SOLUTION > > I think it makes most sense for there to be country-specific packages, > such as django-forms-us or django-forms-es, that are distributed > independently. These would be very easy to install (via pip), and > people outside of the Django core team could maintain them and take > full responsibility for them. > > Considering backwards-compatibility, we could jumpstart these > country-specific packages by (1) creating them in the first place and > (2) replacing the django.contrib.localflavor code with code that > imports from the correct third-party library (e.g., djangoforms_us), > as a shim. For Django 1.5, we'd tell people to install the appropriate > django-forms-* packages for their sites, and their code referencing > django.contrib.localflavor would still work (with a > DeprecationWarning). > > How does this sound? I'm happy to start doing the work myself on Sept. > 1 (http://www.holovaty.com/writing/goodbye-everyblock/). :-) > > Adrian > > -- > 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. > -- 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.
