[Jim Fulton]
> We often want to associate data with threads. Python
> manages a dictionary per-tread for this purpose, but there's
> currently no way to get to this dictionary from Python.
>
> I propose, for 2.4, to add a "local" class to the thread
> module for creating thread-local objects,
It's probably better to add this to the (coded in Python) threading
module, and include the Python implementation there. The threading
module can replace the Python implementation with something from the
(coded in C) thread module if possible. This is so implementations
other than CPython get something usable right away (only CPython has
the C API, of course).
... the doctest ...
> >>> thread
That was meant to be "import thread", right?
> >>> mydata = thread.local()
...
> You can also access the local-object's dictionary:
>
> >>> mydata.__dict__
> {'number': 42}
I like this much better than reimplementing the dict interface one
method at a time! Making __dict__ available is important (IMO) for
the benefit of introspection/system tools written in Python.
...
> Thoughts?
+1.
> Do I need to create a PEP?
Not unless someone starts whining about it <wink -- but it's a small feature>.
BTW, I suggest it would be better if the string key had a
unique-to-this-purpose prefix, e.g. 'threading.local.' +
str(id(self)). I'm uncomfortable with reserving all "string keys that
look like integers" implicitly for this use.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4