[issue21614] Case sensitivity problem in multiprocessing.

Nick Coghlan report at bugs.python.org
Thu Nov 27 02:36:17 CET 2014


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 <report at bugs.python.org>
<http://bugs.python.org/issue21614>
_______________________________________


More information about the Python-bugs-list mailing list