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 -- 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/9eb88cf7-8e38-4b4f-be3d-cda84645eeae%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
