модуль подпроцесса Python: цикличное выполнение по stdout дочернего процесса
По моему опыту, дебаты о, "что является единицей", являются пустой тратой времени.
, Какие вопросы намного больше, "как быстро тест?" Быстрый тестовый прогон по курсу 100 +/second. Медленный тестовый прогон, достаточно медленный, что Вы рефлексивно не выполняете их каждый раз, Вы приостанавливаетесь для размышления.
, Если Ваши тесты являются медленными, Вы не будете выполнять их как часто, делая время между инжекцией ошибки и обнаружением ошибки дольше.
, Если Ваши тесты являются медленными, Вы, вероятно, не извлекаете пользу дизайна из поблочного тестирования.
Хотите быстрые тесты? Следуйте за Michael Feather правила поблочного тестирования .
, Но если Ваши тесты быстры и они помогают Вам написать свой код, кто заботится о том, что маркирует, они имеют?
4 ответа
Вам придется беспокоиться о взаимоблокировках, если вы связываете со своим подпроцессом, т.е. если вы пишете в стандартный ввод, а также читаете из стандартного вывода. Поскольку эти каналы могут быть кэшированы, выполнение такого рода двусторонней связи в значительной степени запрещено:
data_stream = Popen(mycmd, stdin=PIPE, stdout=PIPE)
data_stream.stdin.write("do something\n")
for line in data_stream:
... # BAD!
Однако, если вы '
Ответы SilentGhost / chrispy допустимы, если у вас небольшой или средний объем вывода от вашего подпроцесса. Иногда, однако, может быть много вывода - слишком много для удобной буферизации в памяти. В таком случае нужно сделать start () процесс и создать пару потоков - один для чтения child.stdout и один для чтения child. stderr , где дочерний - это подпроцесс. Затем вам нужно wait () для завершения подпроцесса.
Именно так работает communication () ; Преимущество использования ваших собственных потоков состоит в том, что вы можете обрабатывать вывод подпроцесса по мере его создания. Например, в моем проекте python-gnupg я использую эту технику для чтения вывода состояния из исполняемого файла GnuPG по мере его создания, вместо того, чтобы ждать его всего, вызывая communication () . Приглашаем вас ознакомиться с исходным кодом этого проекта - соответствующие материалы находятся в модуле gnupg.py .
data_stream.stdout - дескриптор стандартного вывода . вы не должны зацикливаться на нем. communication возвращает кортеж из (stdoutdata, stderr) . это stdoutdata , которое вы должны использовать для работы.
Два ответа довольно хорошо уловили суть проблемы: не смешивайте запись чего-либо в подпроцесс, чтение чего-то из него, повторную запись и т. Д. - буферизация канала означает, что вы ' есть риск зайти в тупик. Если вы можете, напишите все, что вам нужно для записи, в подпроцесс ВПЕРВЫЕ, закройте этот канал и только ЗАТЕМ прочитайте все, что должен сказать подпроцесс; общение подходит для этой цели, ЕСЛИ объем данных не слишком велик для размещения в памяти (если это так, вы все равно можете добиться того же эффекта «вручную»).
Если вам нужно более тонкое -grain, посмотрите вместо этого pexpect или, если вы работаете в Windows, wexpect .