threading.Thread.start should return self

[tewalds]

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.

[rhettinger]

The norm in Python is for mutating methods to return None.

[serhiy-storchaka]

threads = [threading.Thread(target=fn, args=(i,)).start() for i in range(10)]

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]

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 start more than once, which clearly doesn't happen in a list comprehension as above.

This version:

threads = []
for i in range(10):
  thread = threading.Thread(target=fn, args=(i,))
  thread.start()
  threads.append(thread)

would also lose the references to all the started threads in threads if start raised 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?