Стратегия для того, чтобы не отставать от (Python) языковых изменений

Написание кода, который будет работать через много лет

Языки программирования меняются. Библиотеки меняются. Некоторый код 5, 10 или даже 20 лет назад может все еще выполняться и давать ожидаемые результаты, тогда как некоторый код за 2 года может завершиться с ошибкой синтаксиса. Это отчасти неизбежно, поскольку языки развиваются (по крайней мере, большинство из них). Разработчики несут ответственность за поддержание своего кода. Но иногда стабильность является важным требованием в производственном коде, и код должен просто выполняться в течение 10 лет без необходимости, чтобы кто-то просматривал код каждый год, чтобы адаптировать его к изменениям языка. Или у меня могут быть небольшие сценарии, например, для анализа научных данных, которые я должен пересмотреть, не касаясь их годами. Например, в метеорологических отделениях имеется много кода на Фортране, работающего даже для несущественных частей, и стабильность кода является одной из причин. Я' Мы слышали, что страх за нестабильность - один из объектов, которые они имеют против перемещения на Python (конечно, кроме языковой инерции; это возможно только для нового кода, не зависящего от старого кода). Конечно, одна из стратегий для стабильного кода - заморозить всю операционную систему. Но это не всегда возможно.

Я использую Python в качестве примера, но проблема не ограничивается Python в частности.

Документы по проблемам совместимости с Python

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

PEP-5

Согласно PEP 5 :

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

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

ОПТОСОЗ 291

PEP 291 содержит неполные списки руководящих принципов, которых следует избегать для обеспечения обратной совместимости. Однако это относится только к Python 2.x. Поскольку Python 2.7 является последним выпуском в серии 2.x, а Python 2.7 предназначен только для исправления ошибок, этот PEP теперь представляет только исторический интерес.

ОПТОСОЗ 387

Существует также PEP 387 о несовместимых назад изменениях. PEP 387 является проектом, а не официальной политикой. В июне 2009 года это обсуждалось в списке рассылки Python-ideas . Часть обсуждения была посвящена тому, как разработчики могут написать код, устойчивый к изменениям языка. В одном посте перечислены некоторые советы о том, что не следует делать :

Наряду с этим есть несколько правил, которые вы можете сделать вывод, которые, вероятно, верны большую часть времени: не вызывайте вещи, начинающиеся с "_", не монтируйте патчи, не используйте динамическую замену классов для объектов из классов, отличных от ваших , не зависите от глубины иерархии наследования (например, нет ".__bases__[0].__bases__[0]"), убедитесь, что ваши тесты выполняются без создания DeprecationWarnings, помните о потенциальных конфликтах пространства имен при добавлении атрибутов в классы, которые наследуются от других библиотек. Я не думаю, что все эти вещи записаны в одном месте, хотя.

Кроме того, были некоторые моменты о «шахтных полях» (новые функции могут измениться) и «замороженных областях» (очень проданные API практически гарантированно не изменятся). Цитирую Антуана Питру :

Я думаю, что «замороженная область» должна определяться положительно (явные публичные API и явно гарантированное поведение), а не отрицательно (явное «минное поле»). В противном случае мы забудем поместить некоторые важные вещи в минное поле и укушаться позже, когда нам нужно будет изменить эти вещи назад-несовместимым способом.

Похоже, из этой ветки нет никаких выводов, но это довольно близко к сути того, что я ищу. Нити уже почти четыре года, поэтому, возможно, ситуация изменилась или улучшилась. Какой код может выжить, а какой код более хрупкий?

Руководство по портированию

В дополнение к документам, изложенным выше, каждая версия Python имеет руководство по портированию : перенос на Python 3.2 , перенос на Python 3.3 и т. Д.

Полезная совместимость

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

С точки зрения программистов

Как программист, я знаю, что Python изменится в будущем, и что люди, особенно я, попытаются запустить мой код, возможно, через несколько лет в версии Python, которая имеет одну, две или, возможно, три второстепенные версии. Не все будет совместимо, и на самом деле легко придумать код, который потерпит неудачу (я однажды сталкивался с указанием кода if sys.version[:3] != '2.3': print 'Wrong version, exiting'). То, что я ищу, - это набор рекомендаций о том, что делать и чего не делать, чтобы повысить шансы того, что мой код все еще будет работать без изменений в будущем.

Есть ли такие рекомендации? Как мне написать код Python, который будет работать в будущем?

Мой вопрос относится как к ядру Python, в стандартной библиотеке, но и часто используемые дополнения библиотек, в частности numpy, scipy, matplotlib.

РЕДАКТИРОВАТЬ : Пока два ответа относятся к python2 против python3. Это не то, что я имею в виду. Я знаю об инструментах для перехода с Python2 на Python3. Мой вопрос касается языковых изменений еще впереди . Мы можем добиться большего успеха, чем хрустальный шар, найти более стабильные правила кодирования. Например:

• import moduleявляется более перспективным, чем from module import *, потому что последний может нарушить код, если moduleвырастет одна или несколько новых функций / классов.

• Использование недокументированных методов может быть менее перспективным, чем использование документированных методов, так как недокументированное может быть признаком нестабильности.

Именно такого рода практические советы по кодированию мне нужны. Поскольку речь идет о настоящем → будущем, мы можем ограничиться Python3, потому что Python2 больше не изменится.

Это нерешенная проблема в нашей области. Нет никакого способа быть уверенным, что ваш код будет работать бесконечно. Даже если ваш код был действительно идеален в прямом совместимом смысле (и если это так, пожалуйста, приходите работать в мою компанию!;)), Если он работает, использует или используется любым другим программным обеспечением, которое получает ошибку или изменения в любом случае, ваш код может не работать.

Поэтому я не могу дать вам список того, что нужно сделать, если вы будете следовать им, это будет гарантией успеха. Но что вы можете сделать, это минимизировать риск будущих поломок и минимизировать их последствия. Более осведомленный Pythonist сможет дать вам совет, более конкретный для Python, поэтому я должен быть более общим:

• написать юнит-тесты. Даже для вещей, которые ты знаешь, они не нужны.

• использование популярных / хорошо спроектированных / стабильных библиотек и технологий, позволяющих избежать непопулярных (и, следовательно, скорее всего, их вскоре не поддержат)

• Избегайте написания кода, который использует детали реализации. Код для интерфейсов, а не реализации. Код против нескольких реализаций одного и того же интерфейса. Например, запустите ваш код на CPython, Jython и IronPython и посмотрите, что произойдет. Это даст вам отличную обратную связь о вашем коде. Это может быть бесполезно для Python3, хотя, как я слышал, некоторые реализации все еще были в Python2.

• написать простой, понятный код, который явно о его предположениях

• написать модульный, компонуемый код. Если какой-то код должен делать что-то опасное (в смысле будущего), отделите его так, чтобы даже если он должен был измениться, остальная часть кода этого не делает.

• иметь спецификацию какой-либо формы. Это похоже на пункты о модульных тестах, если вы используете тесты в качестве спецификации и интерфейсы, которые также можно использовать в качестве спецификаций. (Я имею в виду интерфейс в общем смысле, а не в смысле ключевых слов Java).

Выполнение любой из этих вещей может / увеличит объем работы, которую вы должны сделать. Я думаю, что это имеет смысл - многие из этих пунктов также могут быть сделаны для того, чтобы написать хороший код, что довольно сложно (на мой взгляд). Иногда вам может потребоваться нарушить некоторые из этих предложений. Это вполне приемлемо, но помните о затратах.

Здорово, что команда Python думает об этом, и наверняка они намного талантливее и опытнее, чем я когда-либо. Тем не менее, я бы предположил, что есть 100%, что чей-то код перестанет работать так, как это было задумано при обновлении Python.

Это называется управление конфигурацией. Если система никогда не меняется, она не должна сломаться. Так что не меняйте систему. Беспокоитесь о новых выпусках Python? Не обновляйте. Беспокоитесь о новых драйверах устройств? Не обновляйте. Беспокоитесь о патчах Windows? ...

Для Python 2 -> Python 3 уже установлена библиотека Python 2to3 (она поставляется с оригинальным пакетом Python).

Исходя из этого, вскоре после выпуска новых версий должны появиться похожие библиотеки, которые поставляются с каждой новой версией. Однако, как заявил Мартин, библиотеки, подобные этим, будут выпущены только для основных версий (например, версии 3.0), но не для вспомогательных версий (таких как 3.2). Однако между 3.0 и 3.2 (или любыми другими второстепенными версиями) не должно быть проблем с совместимостью, поэтому переход на версию 3.0 должен быть в порядке.

Также я предлагаю вам взглянуть на этот вопрос .

Мне нечего добавить, «программа для двоих, использующая 2to3» в последнее время, похоже, стала распространенным дополнением к интернету. Однако есть кое-что, на что вы должны обратить внимание:

Это называется шесть (страница Pypi) . Это библиотека Python, предназначенная для помощи в написании кода, который работает как на Python 2, так и на Python 3. Я видел, что он используется в ряде проектов, просматривая сеть, но имена меня сейчас избегают.