Olivier Grisel added the comment: I agree that a failure to lookup the module should raise an explicit exception.
> Second, there is no way that 'nosetests' will ever succeed as an import > since, as Oliver pointed out, it doesn't end in '.py' or any other > identifiable way for a finder to know it can handle the file. So this is not > a bug and simply a side-effect of how import works. The only way around it > would be to symlink nosetests to nosetests.py or to somehow pre-emptively set > up 'nosetests' for supported importing. I don't agree that (unix) Python programs that don't end with ".py" should be modified to have multiprocessing work correctly. I think it should be the multiprocessing responsibility to transparently find out how to spawn the new process independently of the fact that the program ends in '.py' or not. Note: the fork mode works always under unix (with or without the ".py" extension). The spawn mode always work under windows as AFAIK there is no way to have Python programs that don't end in .py under windows and furthermore I think multiprocessing does execute the __main__ under windows (but I haven't tested if it's still the case in Python HEAD). ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue19946> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
