> It seems the addition of the initargs argument doesn't tackle Mark's objection here:

> > the initialiser and uninitialiser for the EnhancedThreadPoolExecutor
> > accept no arguments. In retrospect, it would have been better to have 
> > them take the thread itself as a single argument.

This would be inconsistent with multiprocessing.Pool's initializer/initargs behavior. I'm not sure if consistency is important there or not, but its worth pointing out.

I'm also not sure how useful it would be for ProcessPoolExecutor to receive an instance of itself. With multiprocessing.Pool,  initializer is a commonly used to pass objects that can only be inherited to workers (Queues, Locks, etc.). The same pattern would be useful for ProcessPoolExecutor, which means initializer needs to be able to take an arbitrary number of arguments, rather than just an instance to the Process object itself.