Запуск сценария Python одновременно по сети. Это нормально?

Question

Запуск сценария Python одновременно по сети. Это нормально?

1

У нас есть python script + связанные модули на сетевом диске. Мы запускаем этот script одновременно с нескольких компьютеров одновременно.

Иногда один из них случайным образом терпит неудачу с такой ошибкой:

Traceback (most recent call last):
  File "\\chifs02.int.tt.local\group\Development\Server Products\Automation\repos\mksutils\fetch.py", line 16, in <module>
    from scripts import write_set_environment
NameError: Can't find file for module scripts
(filename \\chifs02.int.tt.local\group\Development\Server Products\Automation\repos\mksutils\scripts.pyc)

Одна странность, которую я заметил, это то, что файл .py был последним изменен несколько месяцев назад, но .pyc всего лишь несколько часов, несмотря на то, что он был запущен по крайней мере ежедневно с тех пор.

Я никогда раньше не видел эту ошибку NameError: Can't find file for module scripts, и Google не очень помогает.

Все задействованные компьютеры работают под управлением Windows.

Matthew Scouten 13 май 2011, в 19:37

Источник

1

Эта проблема решена в Python 3.x, в котором файлы .pyc __pycache__ в отдельный каталог __pycache__ и __pycache__ ими в соответствии с конкретной __pycache__ Python, для которой они скомпилированы.
Katriel 13 май 2011, в 18:25
0

@katrielalex Приятно знать, но по нескольким техническим причинам мы не будем Python 2.6 или 2.7 в обозримом будущем.
Matthew Scouten 13 май 2011, в 18:31

Теги:

python

windows

networking

2 ответа

2

Это странная ошибка (я никогда не видел ее в дикой природе).

Моя гипотеза заключается в том, что она связана с одним node регенерированием файла pyc, а другой node пытается посмотреть на него. Попытка удалить файлы pyc и указать -B в командной строке Python:

-B     : don't write .py[co] files on import; also PYTHONDONTWRITEBYTECODE=x

NPE 13 май 2011, в 14:30

Ещё вопросы

Эта проблема решена в Python 3.x, в котором файлы .pyc __pycache__ в отдельный каталог __pycache__ и __pycache__ ими в соответствии с конкретной __pycache__ Python, для которой они скомпилированы.
@katrielalex Приятно знать, но по нескольким техническим причинам мы не будем Python 2.6 или 2.7 в обозримом будущем.

Nicholas Knight · Accepted Answer · 2011-05-13T15-56-00.000Z

Не делайте этого, где "that" имеет несколько компьютеров, пытающихся использовать один и тот же .pyc(s).

Вероятная причина, по которой модифицируется pyc, заключается в том, что у вас, вероятно, несколько разных версий Python на разных компьютерах. Один пишет свою версию .pyc, а другой приходит и видит, что это не то, что он ожидал, и пишет свою собственную версию.

Меня нисколько не удивит, узнав, что странные ошибки возможны в ситуации, когда разные компьютеры одновременно пытаются разобраться с теми же .pyc файлами. Это приглашение для условий гонки, так как не используется механизм блокировки.

Либо каждая система скопирует script в локальное место перед ее запуском или отключит генерацию .pyc(-B командной строки или задает переменную среды PYTHONDONTWRITEBYTECODE).