On Friday, February 14, 2014 10:53:11 AM UTC-5, Florian Apolloner wrote: > > 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. >
Of course. I meant this just in the sense that it gave us encouragement to try it out. > > >> 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… > Well, even if it turns out to be 'never', The @uses_settings decorator basically means that Django can continue operating as-is, and outside projects can still call in to methods using arguments instead of bootstrapping settings. I should be able to name-names, but I know I've occasionally run into wanting to use some of these methods passing in a custom variable, even in a django project that's not in settings, and it's not always available as an option. This puts a pattern behind it. Also, whereas truly purging all settings from methods might be never, I can imagine a few easy/minor refactorings (even backwards compatible ones) where, for example, I send/put my DB settings into, e.g. database manager or the model, and then I don't have to keep on putting in db='' somewhere else. This is not an actual proposal -- just an example of where organization might make a particular module easier to use as a library without continuing to send a setting at every call, with no harm (and possibly even some benefit) to Django's use of 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. > I think the main thing that converting other Django modules achieves is seeing how far our approach can go in all the contexts settings is used. The bare branch of just the utils.unsetting library is available here: https://github.com/schuyler1d/django/tree/unsetting_base and if it was desirable, I imagine it wouldn't be pulled in as all one patch, but evaluated/discussed per-module. But as you said, let's discuss the approach here first. cheers, sky > 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/496ab439-5591-4c44-a3fa-95c09694ad6a%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
