Удивительно, если python может вводить проверки в пределах своей фазы компиляции заданного py на pyc для защиты от поврежденного pyc из-за внезапного отключения системы (и диска). Когда система вернется, будет существовать проверяемый pic для целостности , и если его рассматриваемый подозреваемый, регенерированный?Python pyc возможен, когда питание циклически?
Насколько я знаю, процесс компиляции в байт-код работает так же, как обычный make в том, как он обрабатывает перекомпиляцию; он проверяет, являются ли скомпилированные файлы старше исходных файлов, и если они перекомпилируются, а если они не остаются, они будут. Мое лучшее предложение было бы просто очистить файлы PYC всякий раз, когда подозревается внезапный отказ питания, и делать импорт, чтобы получить новые (возможно, вы, возможно, автоматизируете это, чтобы упростить его).
Обратите внимание, что я не экспериментировал, чтобы увидеть, будет ли Python ждать, пока файл байт-кода не будет завершен до записи на диск; если это так, это уменьшит вероятность такого рода коррупции, о котором вы говорите, поскольку файл PYC просто не будет записан на диск, если начнется сбой питания при фактической компиляции. Тем не менее, коррупция по-прежнему будет проблемой, если потери мощности происходят во время записи, так как я считаю, что большинство ОС обновляют время модификации файла, когда файл открывается с доступом к записи, а не когда дескриптор файла закрыт.
Если я правильно интерпретирую this message, Python 3.3 создаст файл .pyc под другим именем и переименует его при успешном завершении. Я думаю, что это «атомный» (их термин), поскольку он попадает в этом контексте, и это, безусловно, защитит вас от внезапного крушения или потери власти. Более ранние версии (включая ветвь 2. *), по-видимому, по-прежнему подвержены условиям гонки и недействительны .pyc файлам.
Независимо от того, может ли файл быть недействительным без запуска исключения времени выполнения, это отдельный вопрос. В этой проблеме сообщается, что все говорят о сбое при импорте.
интересный на py3.3; спасибо alexis; повреждение файла pyc вызвало ошибку при импорте, потому что pyc был по существу нулевым файлом (аналогичный размер файла pyc, как если бы пу был пуст, а это не было) – user2471686
Я не уверен, как вы измеряете размер pyc - если файловая система говорит, что он пуст, он пуст; но в любом случае кажется, что ваша проблема соответствует профилю. Большинство отчетов касаются поврежденных файлов, вызванных условиями гонки, например, два процесса python, записывающих один и тот же файл pyc одновременно. – alexis
Thanks @JAB; работа с удаленными полевыми системами, которые могут иметь внезапные потери мощности, и я вижу поврежденные pyc; есть также ошибка, которую я только что видел (http://bugs.python.org/issue13146); несмотря на то, что управление генерацией pyc явно/полностью при запуске системы звучит, как надо, раздражает и будет пытаться автоматизировать - спасибо – user2471686
Очевидно, что у людей также есть подобные проблемы в тех случаях, когда они обновляют модули Python в среде без полномочий root, которые ранее были скомпилированы root/кто-то с более высоким доступом и новыми файлами PYC не перезаписывают существующие из-за ограничений доступа, настолько, что в Python 2.6+ на самом деле можно отключить генерацию файлов PYC, если вы в порядке с производительностью убывать. http://stackoverflow.com/a/154617/138772 – JAB