[issue10437] ThreadPoolExecutor should accept max_workers=None

Daniel Stutzbach added the comment: Amaury Forgeot d'Arc said: > pypy does have a GIL! D'oh. That shows you how much I know about PyPy. Make that "keep in mind that IronPython doesn't have a GIL". ;) Brian Quinlan said: > I think that using the number of CPUs for max_workers makes sense > f

[issue10437] ThreadPoolExecutor should accept max_workers=None

Brian Quinlan added the comment: I think that using the number of CPUs for max_workers makes sense for you but won't for most users. So I wouldn't make it a default. -- ___ Python tracker

[issue10437] ThreadPoolExecutor should accept max_workers=None

Amaury Forgeot d'Arc added the comment: pypy does have a GIL! -- nosy: +amaury.forgeotdarc ___ Python tracker ___ ___ Python-bugs-lis

[issue10437] ThreadPoolExecutor should accept max_workers=None

Daniel Stutzbach added the comment: In my case, each thread launches a CPU-intensive process via subprocess, then waits for it to report output and exit. Also, keep in mind that PyPy and IronPython don't have a GIL (although I'm not a PyPy or IronPython user myself). --

[issue10437] ThreadPoolExecutor should accept max_workers=None

Brian Quinlan added the comment: Daniel, I wasn't trying to avoid importing multiprocessing. What's your use case though? I think that defaulting the number of threads to the numbers of CPUs would trick users into believing that threads are useful for CPU-intensive work in Python ;-) --

[issue10437] ThreadPoolExecutor should accept max_workers=None

New submission from Daniel Stutzbach : ProcessPoolExecutor allows the max_workers parameter to the constructor to be omitted or None, in which case it will set the max_workers based on the number of CPUs. It would be nice if ThreadPoolExecutor's constructor worked the same way; having the sam