Unimaginative Username
kiwifarms.net
- Joined
- May 27, 2025
Python is effectively jeetware.python actually is fast enough if your program is i/o bound and you don't do something extremely retarded, which happens to include an incredibly large number of programs
besides if you have to loop through a million items it's often a sign that you're not using a structure that lets you only loop through the logarithm of a million items
universal law of programming: jeets can easily write incredibly slow and broken code in any language
Try using its thread-local storage:
Python:
Python 3.13.3 (tags/v3.13.3:6280bb5, Apr 8 2025, 14:47:33) [MSC v.1943 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import threading
>>> threading.local().x = 0
>>> threading.local().x
Traceback (most recent call last):
File "<python-input-2>", line 1, in <module>
threading.local().x
AttributeError: '_thread._local' object has no attribute 'x'
>>>
That's odd. I wonder what's going on?
The problem is that this moron doesn't understand what thread-local variables actually are and closed the bug report.FYI, I've used thread-local namespaces with success in several different ways and none of them involved binding the thread-local namespace to global scope. I don't think anything needs to be fixed here.
The SO answer is misleading and perhaps even wrong. The problem it describes is about sharing the thread-local NS *between function calls*. Persisting state between function calls is not a new or mysterious problem, nor unique to thread-local namespaces. In the example they give, rather than a global they could have put it into a default arg or into a class:
Python:def hi(threadlocal=threading.local()): ... class Hi: threadlocal = threading.local() def __call__(self): ... # change threadlocal to self.threadlocal hi = Hi()
This is simply a consequence of Python's normal scoping rules (should be unsurprising) and the fact that threading.local is a class (new instance per call) rather than a function (with the assumption of a singleton namespace per thread).
At most the docs could be a little more clear that threading.local() produces a new namespace each time. However, I don't think even that is necessary and suggest closing this as won't fix.
You can also check out Jimbo Wales' Libel Wiki and read a summary of what thread-local variables are, followed by this gem:
Python
In Python version 2.4 or later, local class in threading module can be used to create thread-local storage.
import threading
mydata = threading.local()
mydata.x = 1
Multiple instances of local class can be created to store different sets of variables.[18] Thus, it is not a singleton.
What it means is that you can call
threading.local()
multiple times from the same thread and get a different namespace each time, which is an awfully strange way of saying that Python's thread-local storage isn't actually thread-local storage.I've considered what can be done about this problem and have come up with a solution. You might even call it a final solution:
