Hi, On Friday, February 14, 2014 3:18:08 PM UTC+1, Schuyler Duveen wrote: > > This work started at the Chicago DjangoCon sprint this past September. > Justin Holmes and I were talking to Adrian (and then roped in Jacob). > After discussing the problem and working out a possible way to move > forward, it seemed like they both liked the idea. >
Even if two core devs like it, our group is a little bit bigger than just those two. > Jacob's use-case was "I'd like to import django.core.mail and use it even > if I'm not running Django" > Ok, that's something we can agree on, I am currently using translations in a non-Django project. > The general idea with #3 is trying to separate out the setting dependency > *first*, and then opportunistically over time, we can start looking for > opportunities to pass settings in a more functional way through our call > chain. > To me that basically reads as never ;) I am also not convinced that passing the settings individually to each function is such a good interface; some APIs (translations) maybe could do well with a Translation object where ugettext etc then are methods on it… So, what do y'all think? And let us know if we can answer any other > questions about the approach. > To be honest, I am currently far from convinced and I think it would be best if you stopped converting all of Django for now and wait for the outcome of a serious discussion here. Regards, Florian -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/9a2c305a-31b1-4f23-a321-a3ca35737a5a%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
