[Python-Dev] Proposal: thread.get_dict

[Jim Fulton]

Armin Rigo wrote:
> Hello Jim,
> 
> On Mon, Jun 28, 2004 at 01:52:34PM -0400, Jim Fulton wrote:
> 
>>AFAIK, only one bit of extension code uses this data.
> 
> 
> I mean, arbitrary extension modules outside of the standard library.  We can
> make sure that all extension modules within the standard library are safe
> against such tampering, of course, but still we'd have to document this new
> backdoor to extension writers so that they can fix their extension modules for
> 2.4 if they care.  This can be considered as a backwards-incompatible change
> for extension writers.  I have sometimes used this dict from an extension
> module and adding new checks there would also defeat the purpose, which was
> also performance.

Fair enough.  I think your concern is definately valid.

>>But, of course, applications that use this data would have to
>>be disciplined about picking keys to avoid conflict.
> 
> 
> I am sure this is not a problem.  I'd advocate using fresh instances of
> 'object' as keys instead of strings, which is even safer.

Yes

> 
>>This is a fine idea, but I think a simpler mechanism will work
>>just as well and avoid the extra dictionary lookup that your suggestion
>>introduces.  I have an application in which these lookups will be done a
>>lot and I want to minimize overhead.
> 
> 
> Then it might be faster to have dedicated operations:
> 
>   thread.setlocal(key, value)
>   thread.getlocal(key)
> 
> They are a single operation (instead of two in thread.getlocals()[key]) and
> they are safer because you don't see the dictionary directly.  I'd be
> perfectly happy if 'key' was actually restricted to be exactly of type
> 'object', which guarantees that nothing bad can occur with the dict, but I can
> live without that if the danger is properly documented :-)

I think this is definately an improvement. I like the idea of restricting the
keys to object instances. The names should have _s to be consistent with other
thread-module names.  I also think that the names should stand alone, so that they
are meaningful without accessing them through the thread module.

How about:

   get_thread_variable(key)
   set_thread_variable(key, value)

where key's class must be object?

Note that get_thread_variable will accept a second argument to specify
a default. If no default is specified and the key is not found, then
a KeyError is raised.

I have to say that I *really* like your suggestion of the thread.local
object.  I'm not sure the elegance isn't worth the extra dictionary lookup.
Actually, for most apps, the elegance is more than worth the extra dictionary
lookup.  I'm gonna do some more investigation of this to see if I can estimate
the impact of the extra lookup on what I'm doing.

Jim

-- 
Jim Fulton           mailto:jim at zope.com       Python Powered!
CTO                  (540) 361-1714            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org