Python 2 для Python 3: не удается заставить работать многопроцессорность

Я перемещаю свой код с python 2.7 на python 3.5 и не могу заставить работать мой многопроцессорный код, что-то вроде следующего кода. "somemodule.py" в том же каталоге, что и основной скрипт.

import multiprocessing as mp

# somemodule is in the same folder as this script
import somemodule

def foo(bar):
    print(bar)
    return

if __name__ == '__main__':
    bar = ("alice","bob")
    pool = mp.Pool(processes=2)
    pool.map(foo, bar)
    pool.close()

Трассировка

Traceback (most recent call last):
  File "<string>", line 1, in <module>
  File "C:\Anaconda3\lib\multiprocessing\spawn.py", line 106, in spawn_main
    exitcode = _main(fd)
  File "C:\Anaconda3\lib\multiprocessing\spawn.py", line 115, in _main
    prepare(preparation_data)
  File "C:\Anaconda3\lib\multiprocessing\spawn.py", line 226, in prepare
    _fixup_main_from_path(data['init_main_from_path'])
  File "C:\Anaconda3\lib\multiprocessing\spawn.py", line 278, in _fixup_main_from_path
    run_name="__mp_main__")
  File "C:\Anaconda3\lib\runpy.py", line 240, in run_path
    pkg_name=pkg_name, script_name=fname)
  File "C:\Anaconda3\lib\runpy.py", line 96, in _run_module_code
    mod_name, mod_spec, pkg_name, script_name)
  File "C:\Anaconda3\lib\runpy.py", line 85, in _run_code
    exec(code, run_globals)
  File "C:\Users\hobboy\Documents\project\pool_test3.py", line 2, in <module>
    import somemodule
ImportError: No module named 'somemodule'

Код работает в Python Console Spyder, но не в IPython (работает с Anaconda3 2.5.0). Рабочие процессы не могут импортировать somemodule, но основной процесс может. Это как-то связано с неадекватностью import somemodule или с чем-то другим? Я немного прочитал синтаксис импорта Python 3, но я все еще не уверен.

Я сделал сообщение на форумах сообщества Anaconda, но это больше касается того, связана ли проблема с Anaconda, а не с самим кодом.

Дополнительная информация:

Для основного процесса (не рабочего) для Python 2.7/3.5 sys.path[0]='' независимо от версии консоли/питона

Интересно, что sys.path[0] различается для рабочих процессов:

Spyder 2.3.8 (Python 2.7)

  • Консоль Python: '' (работает)
  • Консоль IPython: '' (работает)

Spyder 2.3.8 (Python 3.5)

  • Консоль Python: «C:\Users\hobboy\Documents\project» (работает)
  • Консоль IPython: «C:\WINDOWS\system32» (не работает)

Однако основным (не рабочим) процессом для Python 2 и 3 является sys.path=''. Почему sys.path[0] устанавливается по-разному (и непоследовательно) в Python 3


python-3.x python anaconda python-multiprocessing
person hobboy    schedule 14.03.2016    source источник
comment
куда вы положили somemodule.py?   -  person Yen    schedule 14.03.2016
comment
@Yen Извините, возможно, я недостаточно ясно выразился, somemodule.py находится в том же каталоге, что и скрипт. Я обновил пост, чтобы уточнить.   -  person hobboy    schedule 15.03.2016

Ответы (1)


arrow_upward
3
arrow_downward

Посмотрите, что вы получите, если добавите следующий код в самую первую строку вашего скрипта:

import sys; print(sys.path)

Вывод должен включать каталог, в котором находится ваш «somemodule». Если его нет в списке, вы можете явно манипулировать своей средой, добавив каталог в список sys.path (осторожно избегая обратной косой черты) перед импортом модуля.

Другая альтернатива — убедиться, что интерпретатор Python запускается непосредственно из этой папки, чтобы «рабочий каталог» включал в себя somemodule.py.

person Giacomo Lacava    schedule 14.03.2016
comment
Спасибо, это полезно. Таким образом, в соответствии с документами sys.path[0] является текущим каталогом, если он пуст, или предоставленным каталогом сценария. Я создал еще один раздел Дополнительная информация, в котором есть sys.path[0] рабочих процессов в разных ситуациях. Путь зависит от разных консолей и разных версий Python. Это кажется действительно непоследовательным, это предполагаемое поведение или это может быть ошибка? Я еще не добавил рабочий каталог в путь, как вы предлагаете, но я думаю, что это сработает, хотя в этом случае это действительно похоже на обходной путь. - person hobboy; 15.03.2016
comment
@hobboy Я думаю, что это детали реализации, не охватываемые спецификацией Python, поэтому интерпретаторы делают свое дело. Манипулирование sys.path очень распространено. Еще одна вещь, которую вы можете сделать, это использовать относительный импорт (.somemodule), чтобы механизм всегда смотрел в каталог сценария, а не через sys.path. - person Giacomo Lacava; 15.03.2016