Python 2.7.3 (default, Apr 10 2012, 23:31:26) [MSC v.1500 32 bit (Intel)] on win32

Type "help", "copyright", "credits" or "license" for more information.

The docs claim that "multiprocessing.dummy replicates the API of multiprocessing but is no more than a wrapper around the threading module." however dummy's Pool method does not replicate the API of multiprocessing's Pool method:

>>> import inspect
>>> import multiprocessing
>>> inspect.getargspec(multiprocessing.Pool)
ArgSpec(args=['processes', 'initializer', 'initargs', 'maxtasksperchild'], varargs=None, keywords=None, defaults=(None, None, (), None))
>>> import multiprocessing.dummy
>>> inspect.getargspec(multiprocessing.dummy.Pool)
ArgSpec(args=['processes', 'initializer', 'initargs'], varargs=None, keywords=None, defaults=(None, None, ()))

Thus when attempting to downshift from multiprocessing to threading like so...

import multiprocessing.dummy as multiprocessing

...code that supplies the maxtasksperchild argument to Pool() will not run.

I've confirmed that the behaviour is identical in 3.4.1 on Windows.

Note: To my knowledge there is little or no benefit to using maxtasksperchild when the implementation is using threads. Cleaning up worker processes intermittently will guarantee that memory, handles, etc., are returned to the OS. But memory and handles allocated in a thread are not freed when the thread exits (with the exception of explicitly thread local stuff, which isn't common); it's all using the same heap, and memory allocated by thread 1 is indistinguishable from memory allocated by thread 2.

It's not a bad idea to keep the interface consistent, but I'm not sure it's a good idea to offer and implement a behavior that isn't actually accomplishing anything. Anyone else have any thoughts?

Actually, now that I think about, most thread local stuff wouldn't be freed automatically either, since it's still allocated from a common pool of memory, and interleaved allocations would still prevent memory blocks from being returned to the OS. As far as behavior goes, assuming you aren't explicitly checking thread IDs (which should be meaningless to worker threads anyway; the tasks are assigned arbitrarily), clearing out the thread local storage when a thread exits would be equivalent to ending one worker thread and starting a new one.