[Tutor] threading.currentThread() always same across request ?

Andreas Kostyrka andreas at kostyrka.org
Sat Apr 14 20:11:53 CEST 2007

* Kent Johnson <kent37 at tds.net> [070414 19:53]:
> Andreas Kostyrka wrote:
> > * Kent Johnson <kent37 at tds.net> [070414 19:30]:
> >> Rather than store your attributes directly in the thread, it would 
> >> probably be better to use a threading.local() object as the container.
> >> http://docs.python.org/lib/module-threading.html#l2h-3416
> >>
> >> I don't really know if it makes any difference but this is the supported 
> >> mechanism for thread-local storage.
> > 
> > Well, the other mechanism is also supported, because subclassing
> > threads is allowed, and subclasses need to keep their attributes, even
> > if accessed via threading.currentThread().
> That's a good point. Does anyone know when to prefer threading.local() 
> vs thread attributes?
It's design question, I guess:

*) if you have thread subclasses, then use thread attributes.
*) if you have standard threads, then use thread.local().

The idea is, that it's "rude" to stick attributes on an object that is
not owned by you.

*) Somebody might decide to make threading.Thread be a new style
object with __slots__ => your code breaks.

I know, it's unprobably, but if you derive a subclass, you can be at
least sure that the object will have a __dict__ ;)


More information about the Tutor mailing list