Источник: Deprecations between Python 2.7 and 3.x
Недавнее обсуждение в python-dev выявило проблему, связанную с текущими правилами устаревания интерфейсов Python, с которой сталкиваются разработчики при миграции кода с Python 2.7 на текущие версии Python 3.x. В качестве решения данной проблемы команда разработчиков изменила существующие правила устаревания с учетом того, что программисты чаще всего будут портировать код с Python 2.7 сразу на последнюю версию 3.x, минуя более старые версии.
В Python существует сильная приверженность к поддержанию обратной совместимости. Изменения разрешаются только в случае соблюдения правил совместимости, которые, по сути, заключаются в том, что правильно написанные программы не должны ломаться при исполнении новой версией Python. Однако, это не всегда возможно, например, если API абсолютно не рабочий и должен быть заменен. В таком случае Python следует политике устаревания, основанной на одногодичном переходном периоде, во время которого возможности, которые вскоре будут удалены, становятся официально устаревшими. В течение переходного периода при попытке использования устаревшей возможности должно выдаваться соответствующее предупреждение, чтобы дать разработчикам время обновить свой код. Полная информация о политике устаревания описана в PEP 5. Поскольку изменения появляются только в новых выпусках Python, а обычно интервал между выпусками составляет 18 месяцев, нормальным оказывается период устаревания длительностью в один выпуск.
Единственным исключением такой стратегии был Python 3. Замена основной версии с Python 2 на Python 3 была сделана намеренно, чтобы допустить изменения, нарушающие обратную совместимость, и дать шанс разработчикам языка Python исправить те проблемы, которые не могли быть решены в рамках существующей политики. Например, создание строк по умолчанию в Unicode, возврат итераторов вместо списков.
Учитывая то, что переход к Python 3 потребует времени, около 5 лет по многочисленным оценкам, в этот период ожидалась, в некоторой степени, параллельная разработка на Python 2 и 3.
Было решено, увеличить период поддержки Python 2.7, последнего выпуска Python 2, на значительный срок. В итоге, разработчики, которые захотят перейти на более новую версию Python, должны будут переходить на Python 3.
Здесь-то как раз и проблема...
Один из участников дискуссии в python-dev обратил внимание на то, что определенная функция в C API, а именно PyCObject_AsVoidPtr, была удалена без достаточно заметного предупреждения. А это именно то, от чего политика устаревания должна была защищать. Что же случилось?
Данное изменение было частью миграции со старого API (PyCObject) на новый, усовершенствованный (PyCapsule). Проблема в том, что в 2.6 по умолчанию используется PyCObject, единственно доступный API в Python 2.6, который был объявлен устаревшим в Python 2.7. В Python 3.2 данный API отсутствует и должено использоваться новый - PyCapsule. Получается, что период объявленного устаревания, с выпуска Python 2.7 (июль 2010) до выпуска Python 3.2 (февраль 2011), составил около 7 месяцев. Что значительно меньше 12 месяцев и усложняет разработчикам поддержку приложений для достаточно широкого набора версий Python.
Для тех, кто переходит с версии 3.0 на 3.1, а затем на 3.2, процесс устаревания проходит хорошо. Python 3.1 вышел в марте 2010 с необходимыми уведомлениями об устареваниях, поэтому в рамках версий 3.х период устаревания длился почти 12 месяцев. Однако, это не тот путь, которому, на самом деле, следуют разработчики - они переходят с 2.7 сразу на последнюю версию 3.х, в данном случае 3.2, и, как следствие, получают данную проблему. Возникновение такой ситуации никогда не являлось целью python-dev, но PEP 5 не учитывал случай активной разработки параллельно двух версий Python.
Несмотря на то, что поломка PyCObject/PyCapsule API безусловно является проблемой; ее возможно обойти, но, как минимум, у одного участника python-dev возникли сложности с ее преодолением. В общем и целом, такого не должно было произойти.
Конкретно для случая PyCObject/PyCapsule проблема уже существует и с этим ничего не поделаешь. Восстановление PyCObject, в сущности, не вариант, так как только усугубит дальнейшую несовместимость. Тем не менее, по общему мнению возможно, хотя и трудоемко, написать код, который бы подстраивался под API. В действительности, PyCObject API в Python 3.1 был написан как оболочка вокруг PyCapsule API. Было выдвинуто предложение о том, что при необходимости реализация Python 3.1 может быть выделена для использования сторонним кодом. Более того, было решено, что будет написан "ретроактивный" PEP, учитывающий изменение. Он будет описывать причины, оправдывающие изменение, и документировать ресурсы, которые помогут разработчикам в миграции.
В более общих чертах, команда разработчиков Python обратила внимание на проблему и будет работать над тем, чтобы она не возникла вновь. Гвидо описал данную ситуацию и предложил, чтобы Python 3 старался не использовать устаревания в данный момент. Как минимум, устаревшие API будут поддерживаться значительно дольше, чтобы дать возможность разработчикам корректно смигрировать с Python 2.7.
Независимо от этого, участниками дискуссии был поднят вопрос о том, как более эффективно сообщать об изменениях в Python широкой аудитории. Для решения данной задачи и был создан этот блог.
Во-первых, это означает, что разработчики Python не всегда делают все правильно. Ни у кого не было намерений усложнять жизнь разработчикам, просто эта проблема не была вовремя замечена.
Во-вторых, исправление такой ситуации может больше навредить, чем помочь, поэтому PyCObject API не будет восстановлен. Хотя восстановление, возможно, поможет разработчикам, столкнувшимся с изменением API, но в ситуация с поддежкой совместимости только усложнилась бы. Тем временем, мы должны смириться с этой проблемой и двигаться дальше. Уроки усвоены, и мы постараемся не повторять тех же ошибок.
Эта история в том числе свидетельствует о том, что команда разработчиков Python хочет иметь обратную связь от пользователей. Совместимость очень важна, и мы прилагаем все усилия, чтобы переход на новые версии был безболезненным, насколько это возможно. В частности, разработчики библиотек должны иметь возможность поддерживать различные версии Python, прикладывая при этом не слишком много усилий.
И наконец, разработчики не бросили 2.7. Несмотря на то, что не будет появляться новых возможностей и не будет версии 2.8, взгляды людей, использующих 2.7, по-прежнему важны. Для всего сообщества Python очень важно дать возможность пользователям перейти на версии 3.х в тот момент, когда они будут готовы.
Недавнее обсуждение в python-dev выявило проблему, связанную с текущими правилами устаревания интерфейсов Python, с которой сталкиваются разработчики при миграции кода с Python 2.7 на текущие версии Python 3.x. В качестве решения данной проблемы команда разработчиков изменила существующие правила устаревания с учетом того, что программисты чаще всего будут портировать код с Python 2.7 сразу на последнюю версию 3.x, минуя более старые версии.
Прeдпосылки
В Python существует сильная приверженность к поддержанию обратной совместимости. Изменения разрешаются только в случае соблюдения правил совместимости, которые, по сути, заключаются в том, что правильно написанные программы не должны ломаться при исполнении новой версией Python. Однако, это не всегда возможно, например, если API абсолютно не рабочий и должен быть заменен. В таком случае Python следует политике устаревания, основанной на одногодичном переходном периоде, во время которого возможности, которые вскоре будут удалены, становятся официально устаревшими. В течение переходного периода при попытке использования устаревшей возможности должно выдаваться соответствующее предупреждение, чтобы дать разработчикам время обновить свой код. Полная информация о политике устаревания описана в PEP 5. Поскольку изменения появляются только в новых выпусках Python, а обычно интервал между выпусками составляет 18 месяцев, нормальным оказывается период устаревания длительностью в один выпуск.
Единственным исключением такой стратегии был Python 3. Замена основной версии с Python 2 на Python 3 была сделана намеренно, чтобы допустить изменения, нарушающие обратную совместимость, и дать шанс разработчикам языка Python исправить те проблемы, которые не могли быть решены в рамках существующей политики. Например, создание строк по умолчанию в Unicode, возврат итераторов вместо списков.
Параллельные пути разработки
Учитывая то, что переход к Python 3 потребует времени, около 5 лет по многочисленным оценкам, в этот период ожидалась, в некоторой степени, параллельная разработка на Python 2 и 3.
Было решено, увеличить период поддержки Python 2.7, последнего выпуска Python 2, на значительный срок. В итоге, разработчики, которые захотят перейти на более новую версию Python, должны будут переходить на Python 3.
Здесь-то как раз и проблема...
Неожиданные устаревания
Один из участников дискуссии в python-dev обратил внимание на то, что определенная функция в C API, а именно PyCObject_AsVoidPtr, была удалена без достаточно заметного предупреждения. А это именно то, от чего политика устаревания должна была защищать. Что же случилось?
Данное изменение было частью миграции со старого API (PyCObject) на новый, усовершенствованный (PyCapsule). Проблема в том, что в 2.6 по умолчанию используется PyCObject, единственно доступный API в Python 2.6, который был объявлен устаревшим в Python 2.7. В Python 3.2 данный API отсутствует и должено использоваться новый - PyCapsule. Получается, что период объявленного устаревания, с выпуска Python 2.7 (июль 2010) до выпуска Python 3.2 (февраль 2011), составил около 7 месяцев. Что значительно меньше 12 месяцев и усложняет разработчикам поддержку приложений для достаточно широкого набора версий Python.
Для тех, кто переходит с версии 3.0 на 3.1, а затем на 3.2, процесс устаревания проходит хорошо. Python 3.1 вышел в марте 2010 с необходимыми уведомлениями об устареваниях, поэтому в рамках версий 3.х период устаревания длился почти 12 месяцев. Однако, это не тот путь, которому, на самом деле, следуют разработчики - они переходят с 2.7 сразу на последнюю версию 3.х, в данном случае 3.2, и, как следствие, получают данную проблему. Возникновение такой ситуации никогда не являлось целью python-dev, но PEP 5 не учитывал случай активной разработки параллельно двух версий Python.
Что же нам делать?
Несмотря на то, что поломка PyCObject/PyCapsule API безусловно является проблемой; ее возможно обойти, но, как минимум, у одного участника python-dev возникли сложности с ее преодолением. В общем и целом, такого не должно было произойти.
Конкретно для случая PyCObject/PyCapsule проблема уже существует и с этим ничего не поделаешь. Восстановление PyCObject, в сущности, не вариант, так как только усугубит дальнейшую несовместимость. Тем не менее, по общему мнению возможно, хотя и трудоемко, написать код, который бы подстраивался под API. В действительности, PyCObject API в Python 3.1 был написан как оболочка вокруг PyCapsule API. Было выдвинуто предложение о том, что при необходимости реализация Python 3.1 может быть выделена для использования сторонним кодом. Более того, было решено, что будет написан "ретроактивный" PEP, учитывающий изменение. Он будет описывать причины, оправдывающие изменение, и документировать ресурсы, которые помогут разработчикам в миграции.
В более общих чертах, команда разработчиков Python обратила внимание на проблему и будет работать над тем, чтобы она не возникла вновь. Гвидо описал данную ситуацию и предложил, чтобы Python 3 старался не использовать устаревания в данный момент. Как минимум, устаревшие API будут поддерживаться значительно дольше, чтобы дать возможность разработчикам корректно смигрировать с Python 2.7.
Независимо от этого, участниками дискуссии был поднят вопрос о том, как более эффективно сообщать об изменениях в Python широкой аудитории. Для решения данной задачи и был создан этот блог.
Что все это значит?
Во-первых, это означает, что разработчики Python не всегда делают все правильно. Ни у кого не было намерений усложнять жизнь разработчикам, просто эта проблема не была вовремя замечена.
Во-вторых, исправление такой ситуации может больше навредить, чем помочь, поэтому PyCObject API не будет восстановлен. Хотя восстановление, возможно, поможет разработчикам, столкнувшимся с изменением API, но в ситуация с поддежкой совместимости только усложнилась бы. Тем временем, мы должны смириться с этой проблемой и двигаться дальше. Уроки усвоены, и мы постараемся не повторять тех же ошибок.
Эта история в том числе свидетельствует о том, что команда разработчиков Python хочет иметь обратную связь от пользователей. Совместимость очень важна, и мы прилагаем все усилия, чтобы переход на новые версии был безболезненным, насколько это возможно. В частности, разработчики библиотек должны иметь возможность поддерживать различные версии Python, прикладывая при этом не слишком много усилий.
И наконец, разработчики не бросили 2.7. Несмотря на то, что не будет появляться новых возможностей и не будет версии 2.8, взгляды людей, использующих 2.7, по-прежнему важны. Для всего сообщества Python очень важно дать возможность пользователям перейти на версии 3.х в тот момент, когда они будут готовы.
Комментариев нет:
Отправить комментарий