Author dan.oreilly
Recipients bquinlan, dan.oreilly, pitrou, sbt, tbrink
Date 2014-07-31.02:00:37
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1406772037.24.0.67836931677.issue11271@psf.upfronthosting.co.za>
In-reply-to
Content
re: Diverging ThreadPoolExecutor and ProcessPoolExecutor APIs. I thought about this as well. It would of course be possible to make ThreadPoolExecutor's API match, but it would serve no useful purpose that I can think of. I guess we could make the ThreadPoolExecutor API accept the chunksize argument just so the APIs match, but then not actually use it (and document that it's not used, of course). That would make it easier to switch between the two APIs, at least.

On the other hand, the two APIs are slightly different already: ThreadPoolExecutor requires max_workers be supplied, while ProcessPoolExecutor will default to multiprocessing.cpu_count(). So this wouldn't completely be without precedent.

Anyway, I will review your comments on the patch, add unit tests, and re-submit. Thanks!
History
Date User Action Args
2014-07-31 02:00:37dan.oreillysetrecipients: + dan.oreilly, bquinlan, pitrou, tbrink, sbt
2014-07-31 02:00:37dan.oreillysetmessageid: <1406772037.24.0.67836931677.issue11271@psf.upfronthosting.co.za>
2014-07-31 02:00:37dan.oreillylinkissue11271 messages
2014-07-31 02:00:37dan.oreillycreate