Проблемы разработки и распространения Python 3

Question

Предположим, я разработал универсальную утилиту для конечного пользователя, написанную на Python. Ранее у меня была только одна доступная версия, которая подходила для Python позже, чем версия 2.3 или около того. Достаточно было сказать: «Если вам нужно, загрузите Python, а затем запустите этот скрипт». В системе контроля версий была только одна версия скрипта (я использую Git) для отслеживания.

С Python 3 это уже не обязательно верно. В обозримом будущем мне нужно будет одновременно разработать две разные версии: одну, подходящую для Python 2.x, и другую, подходящую для Python 3.x. С точки зрения развития, я могу придумать несколько вариантов:

1. Поддерживайте два разных скрипта в одной ветке, улучшая оба одновременно.
2. Поддерживайте две отдельные ветви и объединяйте общие изменения по ходу разработки.
3. Поддержка только одной версии скрипта, а также проверка в файле патча, который преобразует скрипт из одной версии в другую. Когда будет сделано достаточно изменений, чтобы исправление больше не применялось корректно, разрешите конфликты и создайте новое исправление.

В настоящее время я склоняюсь к варианту 3, так как первые два будут связаны с большим количеством склонных к ошибкам скуки. Но вариант 3 кажется грязным, и моя система контроля версий должна управлять патчами для меня.

Для дистрибутивной упаковки есть еще варианты на выбор:

1. Предложите два разных пакета загрузки, один из которых подходит для Python 2, а другой - для Python 3 (пользователь должен знать, чтобы загрузить правильный пакет для любой версии Python, которую он имеет).
2. Предложите один пакет для загрузки с двумя различными сценариями внутри (а затем пользователь должен знать, чтобы запустить правильный).
3. Один загружаемый пакет с двумя сценариями, зависящими от версии, и небольшим загрузчиком заглушек, который может работать в обеих версиях Python, который запускает правильный сценарий для установленной версии Python.

Опять же, я сейчас склоняюсь к варианту 3, хотя я еще не пытался разработать такой загрузчик заглушек.

Есть еще идеи?

Answer 1

Редактировать: Мой первоначальный ответ был основан на состоянии 2009 года, с Python 2.6 и 3.0 в качестве текущих версий. Теперь, с Python 2.7 и 3.3, есть другие варианты. В частности, теперь вполне возможно использовать единую базу кода для Python 2 и Python 3.

См. Портирование кода Python 2 на Python 3

Оригинальный ответ:

Официальная рекомендация гласит:

Для портирования существующих Python 2.5 или 2.6 Исходный код на Python 3.0, лучший Стратегия заключается в следующем:

1. (Обязательное условие :) Начните с превосходного тестового покрытия.

2. Порт для Python 2.6. Это должно быть не больше работы, чем средний порт из Python 2.x в Python 2. (x + 1). Убедитесь, что все ваши тесты пройдены.

3. (по-прежнему используется 2.6 :) Включите ключ командной строки -3. Это позволяет предупреждения об особенностях, которые будут удален (или изменен) в 3.0. Запустить свой снова протестируйте набор и исправьте код, который вы получаете предупреждения о том, пока есть предупреждений не осталось, и все ваши тесты еще пройти.

4. Запустите переводчик исходного кода 2to3 через дерево исходного кода. (См. 2to3 - автоматический Python 2 до 3 перевод кода для получения дополнительной информации об этом инструмент.) Запустите результат перевод под Python 3.0. Вручную исправить все оставшиеся проблемы, исправить проблемы, пока все тесты не пройдут снова.

Не рекомендуется пытаться писать исходный код, который работает без изменений в оба Python 2.6 и 3.0; ты должен использовать очень искаженный стиль кодирования, например избегая печатных заявлений, метаклассы и многое другое. Если ты поддержание библиотеки, которая должна поддерживать как Python 2.6, так и Python 3.0, лучший подход заключается в изменении шага 3 выше, отредактировав 2.6 версия исходного кода и работает переводчик 2to3 снова, а не редактирование версии 3.0 исходного кода Код.

В идеале вы должны получить одну версию, совместимую с 2.6, которую можно перевести на 3.0 с помощью 2to3. На практике вы не сможете достичь этой цели полностью. Так что вам может потребоваться некоторые ручные модификации, чтобы заставить его работать под 3.0.

Я хотел бы сохранить эти модификации в ветке, как ваш вариант 2. Однако вместо того, чтобы поддерживать окончательную версию 3.0-совместимую в этой ветке, я хотел бы применить ручные модификации до переводов 2to3 и поместите этот модифицированный код 2.6 в вашу ветку. Преимущество этого метода состоит в том, что разница между этой ветвью и магистралью 2.6 будет довольно небольшой и будет состоять только из изменений вручную, а не изменений, сделанных 2to3. Таким образом, отдельные ветви будут проще поддерживать и объединять, и вы сможете извлечь выгоду из будущих улучшений в 2to3.

В качестве альтернативы, возьмите немного подхода "подожди и посмотри". Перейдите к портированию только настолько, насколько вы можете использовать одну версию 2.6 плюс перевод 2to3, и откладывайте оставшиеся изменения вручную до тех пор, пока вам действительно не понадобится версия 3.0. Может быть, к этому времени вам больше не нужны ручные настройки ...

Answer 2

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

Я думаю, что сейчас имеет смысл продолжать разработку для 2.x, по крайней мере, в течение нескольких месяцев, вплоть до года. В какой-то момент будет просто время объявить окончательную стабильную версию для 2.x и разработать следующие для 3.x +

Например, я не буду переходить на 3.x, пока некоторые из основных фреймворков не пойдут по этому пути: PyQt, matplotlib, numpy и некоторые другие. И я не против, если в какой-то момент они прекратят поддержку 2.x и просто начнут разрабатывать для 3.x, потому что я буду знать, что через некоторое время я тоже смогу перейти на 3.x.

Answer 3

Для разработки вариант 3 слишком громоздкий. Поддержание двух ветвей - самый простой способ, хотя способ сделать это будет различным в разных VCS. Многие DVCS будут более довольны отдельными репозиториями (с общим происхождением, помогающим объединяться), а централизованная VCS, вероятно, будет легче работать с двумя ветвями. Вариант 1 возможен, но вы можете пропустить что-то для слияния и немного более подверженный ошибкам IMO.

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

Answer 4

Я бы начал с перехода на 2.6, что очень близко к python 3.0. Возможно, вы даже захотите подождать 2.7, что будет еще ближе к python 3.0.

И затем, после того, как вы перейдете на 2.6 (или 2.7), я предлагаю вам просто сохранить только одну версию скрипта с такими вещами, как «if PY3K: ... else: ...» в редких местах, где это будет обязательно. Конечно, это не тот код, который нам нравится писать разработчикам, но тогда вам не нужно беспокоиться об управлении несколькими скриптами, ветвями, патчами или дистрибутивами, что станет кошмаром.

Что бы вы ни выбрали, убедитесь, что у вас есть тщательные тесты со 100% охватом кода.

Удачи!

Answer 5

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

В отношении развития трудно сказать, не зная своей аудитории. Пользователи Power Python, вероятно, оценят, что не нужно загружать две копии вашего программного обеспечения, но для более общей пользовательской базы оно, вероятно, «просто работает».