python 3 семантически версионно-совместимый - PullRequest
Новая
       61

python 3 семантически версионно-совместимый

1 голос
/ 26 февраля 2020

Я смотрю на какое-то программное обеспечение, которое хочет ввести Python 3.6 для использования в среде, где 3.5 является стандартом. Читая документацию Python, я не могу найти ничего о том, будет ли

  • 3.5 репрезентативным для семанти c номер версии
  • 3.6 будет соответствовать форварду обновление (ie: код, написанный для среды выполнения 3.5, гарантированно будет работать в среде 3.6)

Тот факт, что эта страница о переносе на 3.7 существует, заставляет меня сильно задуматься нет но я не вижу официальных документов о том, что означают номера версий (если вообще что-то, аля Linux версия ядра)

В более общем смысле - есть ли PEP вокруг совместимости стандарты в потоке выпуска 3.X?

Ответы [ 2 ]

2 голосов
/ 26 февраля 2020

Вот документ об обновлении до 3.6 .

Если бы в вашем коде было, например, open(apath, 'U+'), то в 3.6 он потерпит неудачу. Итак, ясно, что Python 3.6 не полностью обратно совместим с каждым использованием в 3.5.

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

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

Для пояснения терминологии Python использует номенклатуру major.minor.micro для готовых к выпуску выпусков. Таким образом, для Python 3.1.2 final, это основная версия 3, вспомогательная версия 1 и микро версия 2.

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

Также читайте PEP440 , который предназначен для модулей, а не для выпуска новых версий самой python, но все еще актуален для Философия экосистемы.

0 голосов
/ 26 февраля 2020

Короткий ответ «Нет», длинный ответ «Они стремятся к чему-то близкому».

Как правило, микро-версии соответствуют правилам управления версиями semanti c; они не должны ничего ломать или добавлять функции, просто исправлять ошибки. Это не всегда так (например, 3.5.1 сломался vars() на namedtuple, потому что это вызвало ошибку, которая была хуже, чем разрыв, когда он возник ), но это очень редко для кода (особенно для уровня Python уровня, в отличие от C расширений) выходить за пределы микро-границы.

Незначительные версии в основном "добавляют функции", , но они также внесут обратно несовместимые изменения с предварительным предупреждением . Например, async и await стали ключевыми словами в Python 3.7 , что означало код, использующий их как имена переменных, но с включенными предупреждениями вы бы увидели DeprecationWarning в 3,6 . Многие синтаксические изменения изначально вводятся как необязательные импорты из специального модуля __future__ с документированными временными рамками, которые становятся поведением по умолчанию.

Ни одно из изменений, внесенных в второстепенные выпуски, не является широкими; Я сомневаюсь, что какое-либо отдельное осуждение или изменение синтаксиса затронуло даже 1% существующего исходного кода, но это происходит. Если у вас есть сто сторонних зависимостей, и вы переходите на минорную версию или две, есть нетривиальный шанс, что одна из них будет нарушена изменением (пример: pika до 0.12 использовал async в качестве имени переменной и сломался на Python 3.7, они выпустили новые версии, которые исправили ошибку, но, конечно, переход с 0.11 и ниже на 0.12 и выше изменил свой собственный API таким образом, что может нарушить ваш код).

Основные версии примерно такие, как вы ожидаете; ожидаемые / разрешенные назад несовместимые изменения ожидаются / допускаются (хотя они, как правило, не делаются легкомысленно; чем больше изменение, тем больше выгода).

Дело в том, что это близко к версии semanti c, но в интересах из-за отсутствия основных выпусков каждые несколько лет, а также не позволяя языку застаиваться из-за строгих ограничений совместимости, второстепенные выпуски могут разбивать небольшие объемы существующего кода до тех пор, пока существует предупреждение (как правило, в форме фактических предупреждений из кода, использующего код). устаревшее поведение, примечания к документации «Что нового» и иногда поддержка __future__ для упрощения пути миграции.

Все это официально задокументировано (с чуть меньшими подробностями) в их документации цикла разработки :

Для уточнения терминологии Python использует номенклатуру major.minor.micro для готовых к выпуску выпусков. Таким образом, для Python 3.1.2 final, это основная версия из 3, вспомогательная версия из 1 и микро версия из 2.

  • новые основные версии являются исключительными; они появляются только тогда, когда абсолютно несовместимые изменения считаются необходимыми, и планируются очень долго заранее;
  • новые второстепенные версии являются функциональными выпусками; они выпускаются ежегодно из текущей ветки в разработке;
  • новые микро версии являются выпусками исправлений; они выпускаются примерно каждые 2 месяца; они готовятся в отделениях технического обслуживания.
...