RetroSearch Browse

Mon Jun 28 18:29:54 EDT 2004 · https://mail.python.org/pipermail/python-dev/2004-June/045710.html

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.

> 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.

> 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 :-)

A bientot,

Armin.

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2004-June/045710.html below:

[Python-Dev] Proposal: thread.get_dict