Являются ли файлы Python 2.5 .pyc совместимыми с файлами Python 2.6 .pyc?

Некоторое время назад мне пришлось обновить некоторые серверы от Python 2.4 до Python 2.5. Я обнаружил, что .pyc-файлы, созданные под Python 2.4, будут повреждены, когда Python 2.5 попытается их запустить.

Это произойдет снова, когда я обновлюсь с 2,5 до 2,6?

EDIT: Вот немного подробнее

У меня есть файловый сервер, содержащий код python. Доступ к ним осуществляется через Ubuntu и Windows-серверы для запуска кода python. Когда они запускают код, они производят файлы .pyc на файловом сервере.

Я обнаружил, что когда я обновил одну из серверных машин с Python 2.4 до 2.5, у меня были проблемы с файлами .pyc. Я теперь не уверен, была ли это машина с 2.5, которая пыталась запустить 2,4 байт-код или была ли машина 2.4, пытающаяся запустить 2,5 байта, но если бы я удалил байт-код, все прошло хорошо до следующего столкновения байт-кода.

Я обновил все машины до 2,5, и проблема исчезла.

  • Google App Engine Python Webapp2 301 перенаправляет с www на домен без www
  • Функции отправки на Python (PEP 443)
  • python получает список значений из списка dict
  • Получить IP-адрес в Google App Engine + Python
  • Преобразовать строку в объект класса Python?
  • Может ли Python проверять членство нескольких значений в списке?
  • Перемешивание нескольких итераций случайным образом при сохранении их порядка в python
  • Как написать вывод терминала в файл
  • 5 Solutions collect form web for “Являются ли файлы Python 2.5 .pyc совместимыми с файлами Python 2.6 .pyc?”

    В общем, файлы .pyc относятся к одной версии Python (хотя и переносимы на разных машинных архитектурах, если они работают с той же версией); файлы содержат информацию о соответствующей версии Python в своих заголовках, поэтому, если вы оставите соответствующие .py файлы рядом с .pyc , .pyc будет перестраиваться каждый раз, когда для импорта этих модулей используется другая версия Python , «Пытаться запустить» файлы с неправильной версией .pyc – это то, о чем я никогда не слышал. Какие архитектуры были задействованы? Были ли файлы .py такими, какими они должны быть?

    Изменить : поскольку ОП разъяснил, что произошли сбои, когда он запускал программы Python 2.4 и Python 2.5 на тех же .py файлах (с двух разных серверов, совместно использующих сетевой диск), объяснение сбоев становится легким. Файлы .py все время были перекомпилированы – на 2.4 Python, когда 2,5 были теми, которые запускали их совсем недавно, и наоборот – и, следовательно, файлы .pyc были отчаянно заняты, все время переписывались. Чрезвычайно трудно добиться правильной блокировки файлов на сетевых дисках (особенно, но не исключительно в разных операционных системах). Таким образом, должно было произойти следующее (роли могут быть переключены): сервер 2.4 только что определил, что файл .pyc для него и начал его читать; прежде чем он смог закончить чтение, сервер 2.5 (предварительно определивший, что модуль должен быть перекомпилирован) написал над ним; поэтому на сервере 2,4 появился буфер памяти, который имел (скажем) первые 4K байта из версии 2.4 и следующие 4K байта из версии 2.5. Когда он тогда использовал этот искаженный буфер, неудивительно … авария !!!

    Это может быть реальной проблемой, если вы когда-либо постоянно пытаетесь запустить один набор .py файлов из двух или более разных версий Python (даже на том же сервере без дополнительных сбоев сетевых дисков). «Правильное» решение было бы чем-то вроде virtualenv . (Простой, но грязный) хак, который мы приняли на работу (много лет назад, но он все еще в производстве …!) Заключается в исправлении каждой версии Python для создания и использования другого расширения для его скомпилированных файлов байт-кода:. .pyc (или .pyo ) для Python 1.5.2 (которая была самой стабильной версией «системы», когда мы начали делать этот kludge для более новых версий) .pyc-2.0 для 2.0, .pyc-2.2 для 2.2 и т. д. (или, конечно, эквивалентно .pyo-XY ). Я слышал, что это скоро уйдет в прошлое (спасибо Томасу!), Но на протяжении многих-многих лет это было очень прилично для нас по этой щекотливой проблеме.

    Более простое решение состоит в том, чтобы поддерживать единую версию Python, если это возможно для вашей системы; если у вашей системы есть какие-либо осложнения, которые делают невозможным наличие одной версии Python (как это было и сделано, и в наши дни), то в эти дни я бы очень рекомендовал virtualenv , о котором я уже говорил.

    Если у вас есть исходный код, он перекомпилит его для вас. Так что в общем, вы в порядке.

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

    Это также может быть плохо, если у вас есть только файлы pyc. Я просто проверил для вас быстрый тест. Я создал два файла .pyc. Один в 2.5 и один в 2.6. 2.5 не будет работать в версии 2.6, а 2.6 не будет работать в версии 2.5. Оба бросают ошибку «ImportError: Bad magic number in ..», что имеет смысл, потому что магическое число изменилось с 2,5 до 2,6.

    Если вы хотите заранее определить это, вы можете получить магический номер своего Python следующим образом:

     $ python -V Python 2.6.2 # python >>> import imp >>> imp.get_magic().encode('hex') 'd1f20d0a' 

    Чтобы получить магическое число для файла pyc, вы можете сделать следующее:

     >>> f = open('test25.pyc') >>> magic = f.read(4) >>> magic.encode('hex') 'b3f20d0a' >>> f = open('test26.pyc') >>> magic = f.read(4) >>> magic.encode('hex') 'd1f20d0a' 

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

    некоторые причины этого могут не произойти
    – разрешения
    – .py файл недоступен

    В случае проблемы с разрешением Python будет просто использовать .py и игнорировать .pyc (с ценой к производительности)

    Я думаю, что это нормально между младшими версиями, хотя, например, Python2.6.2 .pyc должен работать с Python2.6.4

    Вот выдержка из / usr / share / file / magic

     # python: file(1) magic for python 0 string """ a python script text executable 0 belong 0x994e0d0a python 1.5/1.6 byte-compiled 0 belong 0x87c60d0a python 2.0 byte-compiled 0 belong 0x2aeb0d0a python 2.1 byte-compiled 0 belong 0x2ded0d0a python 2.2 byte-compiled 0 belong 0x3bf20d0a python 2.3 byte-compiled 0 belong 0x6df20d0a python 2.4 byte-compiled 0 belong 0xb3f20d0a python 2.5 byte-compiled 0 belong 0xd1f20d0a python 2.6 byte-compiled 

    Таким образом, вы можете видеть, что правильная версия Python указана с помощью первых 4 байтов файла .pyc

    См. http://www.python.org/dev/peps/pep-3149/ для предлагаемого исправления для этого (надеюсь, в Python 3.2)

    Вам, безусловно, потребуется перекомпилировать файлы байт-кода для их использования. Магическое число байткодов изменилось на каждую основную версию Python (*).

    Однако, если файлы, базирующиеся не на соответствие версиям, никогда не должны приводить к сбою Python. Как правило, он просто игнорирует любой байт-код, который не имеет правильного номера версии, поэтому не должно быть ошибки, оно будет просто медленнее с первого раза, когда оно перекомпилирует (или будет медленнее каждый раз, если пользователь, выполняющий скрипты, не будет У меня нет разрешения на запись для обновления байт-кода).

    (*: и часто на этапах разработки, а также в более ранних версиях он иногда также менялся и над небольшими версиями. См. import.c для полного списка магических чисел и их соответствующих версий Python.)

    Interesting Posts

    Создание плоского списка из многоуровневого вложенного списка

    Как изменить имя тега с помощью BeautifulSoup?

    Get: TypeError: объект dict_values ​​не поддерживает индексирование при использовании python 3.2.3

    многократный импорт python

    python, как отсортировать список списка int, str

    Как остановить Python parse_qs от разбора отдельных значений в списках?

    Каков самый быстрый способ обеспечить, чтобы конкретный столбец был последним (или первым) в кадре данных

    Объемное обновление Django с заменой строки

    Python украшает класс для изменения типа родительского объекта

    Добавить все значения в столбец CSV в Python

    Отображение диаграммы networkx с метками

    Использование класса Python в качестве контейнера данных

    Порог принятия решения Keras для точности и отзыва

    Отображение символов юникода с использованием python

    Пользовательские исключения на Python с кодами ошибок и сообщениями об ошибках

    Python - лучший язык программирования в мире.