Repository navigation
threading.Thread.start should return self #93293
Description
I often write code like:
threads = []
for i in range(10):
thread = threading.Thread(target=fn, args=(i,))
thread.start()
threads.append(thread)
for t in threads:
t.join()
and would really prefer:
threads = [threading.Thread(target=fn, args=(i,)).start() for i in range(10)]
Is there a reason why start doesn't return self here: https://github.com/python/cpython/blob/3.10/Lib/threading.py#L940 ?
An alternative would be to add a start: bool = False param to the Thread constructor such that you can construct it with start=True. I'm not sure why you'd ever want to construct a Thread but not start it, so I wish that could default to true, but clearly it can't due to backwards compatibility.
Activity
rhettinger commentedon May 28, 2022
The norm in Python is for mutating methods to return None.
serhiy-storchaka commentedon May 30, 2022
It is an antipattern. If some of
start()fails you will lose references to all previously started threads, and you cannot know what threads have been started. It is bad for resource management.tewalds commentedon May 30, 2022
The documentation doesn't give any reason to believe it can fail in normal usage. The only documented way to fail is if you call
startmore than once, which clearly doesn't happen in a list comprehension as above.This version:
would also lose the references to all the started threads in
threadsifstartraised an exception. Sure, it's easier to add a try/except, but at the moment it's way more verbose and no safer, with no indication what could fail or how to recover.Assuming it can fail, is additional documentation in order then to specify how it can fail and what to expect when it does so it could possibly be dealt with?
vstinner commentedon Aug 7, 2026
An alternative is to add a start parameter to threading.Thread: see issue gh-155334.