For some background: on DPO, someone suggested a threading.run function. I was in favor of the idea on the basis that threading.Thread has a clunky constructor. That aside, I think we can try to improve it.
In particular, the group parameter is an annoying sharp edge. It's the first positional argument, so threading.Thread(my_function) doesn't work, and instead you get a cryptic error message saying group argument must be None for now. I've fallen victim to this many times.
The docs say that group is reserved for a future ThreadGroup class:
group must be None as it is reserved for future extension when a ThreadGroup class is implemented.
I did some digging, and it seems it was proposed to add a ThreadGroup back in 2014: #66212. Many were not in favor of the idea, as it looked like a worse version of ThreadPoolExecutor. Other than the existence of this parameter, I can't see much reason to ever add a ThreadGroup. So, what do we do about group?
I think it's feasible to deprecate and remove it entirely. We can do this by changing the default group parameter to a private sentinel value, and then if a user passes anything to it (including None), we emit a deprecation warning. In five years, we remove the parameter, making target the first positional parameter and thus allowing Thread(my_function) to work.
Most people use the threading.Thread(target=...) pattern for creating threads, and they won't be broken by a deprecation or a removal. For the people who do use the Thread(None, function) pattern, migrating is fairly trivial.
What do others think? Would a removal result in too much breakage?
For some background: on DPO, someone suggested a
threading.runfunction. I was in favor of the idea on the basis thatthreading.Threadhas a clunky constructor. That aside, I think we can try to improve it.In particular, the
groupparameter is an annoying sharp edge. It's the first positional argument, sothreading.Thread(my_function)doesn't work, and instead you get a cryptic error message sayinggroup argument must be None for now. I've fallen victim to this many times.The docs say that
groupis reserved for a futureThreadGroupclass:I did some digging, and it seems it was proposed to add a
ThreadGroupback in 2014: #66212. Many were not in favor of the idea, as it looked like a worse version ofThreadPoolExecutor. Other than the existence of this parameter, I can't see much reason to ever add aThreadGroup. So, what do we do aboutgroup?I think it's feasible to deprecate and remove it entirely. We can do this by changing the default
groupparameter to a privatesentinelvalue, and then if a user passes anything to it (includingNone), we emit a deprecation warning. In five years, we remove the parameter, makingtargetthe first positional parameter and thus allowingThread(my_function)to work.Most people use the
threading.Thread(target=...)pattern for creating threads, and they won't be broken by a deprecation or a removal. For the people who do use theThread(None, function)pattern, migrating is fairly trivial.What do others think? Would a removal result in too much breakage?