Nick Coghlan added the comment: (Adding Richard as the multiprocessing maintainer, and Christian as the creator of the backport to 2.4/2.5)
Note that on a case-insensitive filesystem, the fopen() call is likely succeeding, and it's the subsequent case_ok() check that's failing. The assumption of case sensitivity is embedded fairly deeply in the import system, as otherwise it makes it pretty easy to accidentally import the same module multiple times under different names. However, if importing the same module multiple times under different names isn't a concern, then setting PYTHONCASEOK should allow multiprocessing to import the module using the incorrect capitalisation. More significant changes to the way the standard library's multiprocessing module starts subprocesses on Windows won't be implemented for Python 2.7 - actually fixing the subprocess spawning to work as intended in all cases (as was done in Python 3.4) relies on the import system changes defined in PEP 451. In theory, I expect a multiprocessing2 backport could be written that depends on importib2 (to enable Python 3.4+ import semantics in Python 2.7), but I'm not aware of anyone currently working on such a project. James's comment sounds like a potentially different problem (e.g. there are some hardcoded platform dependent limits on absolute path lengths for module filenames - 255 in the case of Windows) ---------- nosy: +christian.heimes, sbt _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue21614> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
