Hi Preston, On 30 oct. 2011, at 17:07, ptone wrote: > I do think a better label than "value" could be used for the > thread.local for the current timezone, as this is really a thread > global - something less ambiguous and conflict prone would be better > IMO.
I used this name for consistency with django.utils.translation.trans_real. Thread locals store data as attributes, and there is only one value to store in timezone._active, hence the generic name. Since it's purely internal to django.utils.timezone, there's no risk of conflicts. I think it's fine as is. > Also an explicit link to the activate command from the section > where you introduce the current time zone concept. Good point. I've added a link. > Perhaps with a simple code example of how you would set > current time per user in a view. Yes, I was precisely adding an example to "Selecting the current time zone" :) I'll push it tonight. > Was a threading.local the only way to do this - I'm sure you've given > it some thought - there are relatively few uses of thread locals in > Django - translation being one. If the timezone were stored on the > current request, would that not be available to most places in django > code that need TZ within the current thread? One of the design principles of Django is loose coupling [1]. For instance, this means that "the template system knows nothing about Web requests" -- thanks to whoever wrote the exact quote I needed :) The template and the form layers use the current time zone. (I believe nothing else does.) So, storing the current timezone in the request doesn't really help, since those two layers don't have access to the request. More generally, I agree that global state should be avoided. Thread locals are just a symptom: if you want thread-safe global state, you have to use a thread local. [2] Here, I'm using a small bit of global state to store the current time zone. It's stored exactly like the current locale. I'm not making the situation significantly worse; if we refactor the storage of the locale, it'll be trivial to refactor the storage of the timezone in the same way. Finally, one of the problems of thread locals is that they don't provide strong isolation between threads (everything is in the same memory space after all). From this perspective, storing the current timezone in a thread local isn't nearly as bad as storing the entire request object -- think request.POST['password']. > I think a very brief outline of the steps required for migration may > be worthwhile in the release notes. I agree. I've added some instructions at the bottom of the documentation page, and I'll point there from the release notes. Thanks for your feedback! -- Aymeric. [1] https://docs.djangoproject.com/en/1.3/misc/design-philosophies/#loose-coupling [2] http://groups.google.com/group/django-users/msg/7e7e75325bd086a1 -- 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.
