This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author ncoghlan
Recipients asksol, brett.cannon, brian.curtin, jnoller, michael.foord, ncoghlan, pitrou, vstinner
Date 2011-01-07.04:40:08
SpamBayes Score 4.7432113e-08
Marked as misclassified No
Message-id <1294375213.93.0.894919779182.issue10845@psf.upfronthosting.co.za>
In-reply-to
Content
I'm curious as to the results you get running "python -m test.__main__" and "python Lib/test/__main__.py" as well. I suspect both will fail.

Looking at the forking.py code, I think multiprocessing makes some assumptions that are flat out invalid in the presence of the -m switch - there are no guarantees that you can reverse engineer the name of an arbitrary module from the __file__ attribute. (This actually ties in with the current thread on python-ideas about making the real name of the main module readily available - then the parent process could just pass that through the pipe as a "main_name" value and this problem would go away)

In the short term, however, I think multiprocessing just needs to either special case the situation where "main_name" actually *is* __main__ or just drop the assertion across the board.
History
Date User Action Args
2011-01-07 04:40:14ncoghlansetrecipients: + ncoghlan, brett.cannon, pitrou, vstinner, jnoller, michael.foord, brian.curtin, asksol
2011-01-07 04:40:13ncoghlansetmessageid: <1294375213.93.0.894919779182.issue10845@psf.upfronthosting.co.za>
2011-01-07 04:40:08ncoghlanlinkissue10845 messages
2011-01-07 04:40:08ncoghlancreate