Le vendredi 18 octobre 2013 13:27:21 UTC+2, Anssi Kääriäinen a écrit : > > On Friday, October 18, 2013 1:31:07 AM UTC+3, Shai Berger wrote: >> >> On Thursday 17 October 2013 08:34:48 Aymeric Augustin wrote: >> > >> > For instance, thread locals are strictly equivalent to regular >> variables in >> > tests because they are single threaded (with a handful of exceptions). >> But >> > allowing testing in isolation is a major goal of "removing global >> state". >> >> If I understand correctly, what Jonathan is suggesting is not your >> garden- >> variety thread-local variables, but what Common Lisp calls "dynamically >> scoped >> variables" -- you could call them "call-stack-local" or something like >> that. >> In Python terms, every change to the values of such variables would be >> done in >> the __enter__() of a context manager, and undone (that is, old value >> restored) >> in the __exit__(). I think such variables are a great idea, and would >> indeed >> help a lot with all the problems associated with global state. In terms >> of >> software engineering, they are a lot like exceptions: A channel of >> communications between functions on different levels of the call stack, >> that >> does not require explicit acknowledgement on every level, and yet does >> not >> completely break locality. >> >> However, I don't think such variables can be used in a reliable and >> elegant >> manner without language-level support, and sadly, Python does not support >> them. Attempts I've made to get the functionality using context managers >> ended >> with awkward APIs for either setting values, getting values, or both; as >> a >> trivial example, Jonathan's suggestion of the context manager being >> returned >> by django_project.activate() is of such low granularity, that it is >> almost >> equivalent to regular globals. >> >> If a reasonable API for this can be defined, I'd be all for it. I suspect >> that's a non-trivial "if". >> > > > One possible improvement is to start collecting all global and thread > local state under one object (call it "env" or something like that). That > way it would be a lot easier to actually see what global state you are > using. Currently that isn't at all clear. We have a couple of different > thread-local storages, and then we have a lot of cached values based on > settings, import time actions etc. > > The difficulty of doing this will likely be somewhere between really hard > and impossible. And that environment object might end up as a God Object > for Django (http://en.wikipedia.org/wiki/God_object). So maybe not so > great idea in practice... > > - Anssi >
I'm in favour of everything that makes it easier to see where we still have a global state. About threads, I realised there's the case where you'd use a threadpool in a Django views for optimising stuff. The thread locals wouldn't work there, so that means we would have to offer an API for copying thread locals from one thread to another... Maybe very dirty, but I wonder whether Python has a concept of "parent thread" and whether thread locals could look in there? -- 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 django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. 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/f0e8883d-884c-4cb6-97d4-6597540a5bfe%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
