homepage

In an application with an entry point of __main__.py, multiprocessing.Pool throws the following:
Traceback (most recent call last):
 File "<string>", line 1, in <module>
 File "D:\Dev\Python27\lib\multiprocessing\forking.py", line 346, in main
 prepare(preparation_data)
 File "D:\Dev\Python27\lib\multiprocessing\forking.py", line 454, in prepare
 assert main_name not in sys.modules, main_name
AssertionError: __main__
These messages repeat as long as the application is running.
Demonstration Code, must be in file named __main__.py:
--------------------
import multiprocessing
import time
if __name__ == '__main__':
 pool = multiprocessing.Pool()
 time.sleep(2)
--------------------

I wrapped the offending assertion in a if main_name != '__main__'. I considered not checking the module_name against built-in modules but that seemed likely to be the sort of thing being guarded against, so I left it at an exception for __main__.
Ran a few trivial testing using Pool and Process and it seems to work fine.

Is this on Windows? Does it work for you now?

Sorry about that, yes, this is on Windows XP and 7, 32 bit.
And with the if statement it seems to work fine.
v/r
-- Michael Olson

Ummm, I think I've been unclear on where I was making changes, I changed lib\multiprocessing\forking.py to fix the issue.
Patch attached.

As a note, I didn't attach a patch at first because I was fairly sure I was kludging it into submission, but at least this makes it clear as to what I did.
v/r
-- Michael Olson

The fix from #10845 should be backported to Python 2.7 (bypassing the assertion isn't enough - you want to skip re-executing __main__ entirely)

I applied the patch from #10845 to 2.7.6 and it worked well for me.

Please fix this. Scripts with multiprocessing bundled as wheels are broken with Python 2.7 on Windows: https://github.com/pypa/pip/issues/1891 

Marc's reference to pip meant I noticed something that I had missed previously - that this issue is referring specifically to the use of setuptools/pip entry points, not to the -m switch.
Entry points shouldn't be hitting this if they're importing the module containing the entry point normally - #10845 specifically related to invoking multiprocessing from a module run directly with the -m switch, which was worked around in 3.2 and 3.3, and then finally fixed properly in 3.4 by the implementation of #19946
So if there's an incompatibility between multiprocessing and entry points, it would be preferable to fix it in pip/setuptools, as that will reach many more installations than just fixing multiprocessing to better tolerate that situation.

Please see my latest comments to https://github.com/pypa/pip/issues/1891. 
tl;dr It is related to the -m switch as pip's wheel launcher does 
 PYTHONPATH=script.exe python -m __main__

Thanks for the investigation Marc.
I'd been hesitant to backport the mitigation patch in #10845 to 2.7.x, (as it *does* represent a behavioural change), but if that code path is currently hitting an assert statement anyway, it seems reasonable to make the change for 2.7.11+

New changeset 5d88c1d413b9 by Nick Coghlan in branch '2.7':
Close #10128: don't rerun __main__.py in multiprocessing
https://hg.python.org/cpython/rev/5d88c1d413b9