Перенос кода с Python 2 на Python 3¶Porting Python 2 Code to Python 3

from __future__ import print_function¶

Это личный выбор. 2to3 довольно хорошо обрабатывает перевод оператора print в функцию print, так что это необязательный шаг. Однако этот future-оператор помогает привыкнуть к набору print('Hello, World') вместо print 'Hello, World'.

from __future__ import unicode_literals¶

Ещё один личный выбор. Вы всегда можете пометить то, что должно быть (юникодной) строкой, префиксом u для достижения того же эффекта. Но независимо от того, используете вы этот future-оператор или нет, вы должны точно знать, какие строки Python 2 вы хотите сделать байтами, а какие – строками. Это означает, что вы должны как минимум пометить все строки, предназначенные для текста, префиксом u, если вы не используете этот future-оператор.

Байтовые литералы¶Bytes literals

Это очень важный момент. Возможность помечать строки Python 2, которые должны содержать байты, префиксом b помогает чётко разграничить, что является строкой Python 3, а что – нет. Когда запускается 2to3 на коде, все строки Python 2 становятся строками Python 3, если только они не помечены префиксом b.

Существуют некоторые различия между байтовыми литералами в Python 2 и Python 3, поскольку в Python 2 тип bytes является просто псевдонимом для str. Вероятно, самая большая «ловушка» – это то, что индексация возвращает разные значения. В Python 2 значением b'py'[1] является 'y', а в Python 3 – 121. Избежать этого расхождения можно, всегда выполняя срез размером в один элемент: b'py'[1:2] даёт 'y' в Python 2 и b'y' в Python 3 (то есть, достаточно близко).

В Python 3 нельзя конкатенировать байты и строки. Но поскольку в Python 2 bytes является псевдонимом str, это сработает: b'a' + u'b' работает в Python 2, а b'a' + 'b' в Python 3 вызывает TypeError. Аналогичная проблема возникает и при сравнении байтов и строк.

from __future__ import absolute_import¶

Неявные относительные импорты (например, импорт spam.bacon из модуля spam.eggs с помощью инструкции import bacon) не работают в Python 3. Это выражение __future__ отходит от такой практики и разрешает использование явных относительных импортов (например, from . import bacon).

В Python 2.5 необходимо использовать инструкцию __future__, чтобы получить возможность использовать явные относительные импорты и предотвратить неявные. В Python 2.6 явные относительные импорты доступны и без этой инструкции, но она всё ещё нужна для предотвращения неявных относительных импортов. В Python 2.7 инструкция __future__ не требуется. Другими словами, если вы не поддерживаете только Python 2.7 или версию старше Python 2.5, используйте инструкцию __future__.

from __future__ import division¶

Хотя того же результата можно добиться, используя аргумент -Qnew Python, использование этого future-оператора снимает требование, чтобы пользователи использовали этот флаг для получения ожидаемого поведения деления в Python 3 (например, 1/2 == 0.5; 1//2 == 0).

Указывайте при открытии файла в двоичном режиме¶Specify when opening a file as binary

Если вы не работали в Windows, возможно, вы не всегда утруждали себя добавлением режима b при открытии двоичного файла (например, rb для чтения в двоичном режиме). В Python 3 двоичные файлы и текстовые файлы чётко различаются и взаимно несовместимы; подробнее см. модуль io. Поэтому необходимо принять решение, будет ли файл использоваться для двоичного доступа (чтение и/или запись байтовых данных) или текстового доступа (чтение и/или запись данных Unicode).

Текстовые файлы¶Text files

Текстовые файлы, созданные с помощью open() в Python 2, возвращают байтовые строки, тогда как в Python 3 они возвращают строки Unicode. В зависимости от стратегии переноса это может быть проблемой.

Если требуется, чтобы текстовые файлы возвращали строки Unicode в Python 2, есть две возможности:

• В Python 2.6 и выше используйте io.open(). Поскольку io.open() по сути та же функция и в Python 2, и в Python 3, это поможет устранить любые возможные проблемы.
• Если требуется совместимость с версиями ниже 2.6, тогда используйте codecs.open(). Это гарантирует, что в Python 2 вы получите строки Unicode.

Наследуйте от object¶Subclass object

Классы нового стиля существуют с Python 2.2. Необходимо убедиться, что вы наследуете от object, чтобы избежать странных крайних случаев с порядком разрешения методов и т.д. Это по-прежнему полностью допустимо в Python 3 (хотя и не нужно, так как все классы неявно наследуют от object).

Работа с дихотомией байтов и строк¶Deal With the Bytes/String Dichotomy

Одна из самых больших проблем, с которой сталкиваются люди при переносе кода на Python 3, – это дихотомия байтов и строк. Поскольку в Python 2 тип str мог содержать текстовые данные, люди со временем стали довольно небрежно разграничивать, какие экземпляры str содержат текст, а какие – байты. В Python 3 уже нельзя быть таким беспечным и нужно правильно обрабатывать различие. Ключ к решению этой проблемы – убедиться, что каждый строковый литерал в вашем коде Python 2 синтаксически или функционально помечен как байтовые или текстовые данные. После этого нужно убедиться, что API спроектированы так, чтобы обрабатывать либо конкретный тип, либо быть должным образом полиморфными.

>>> b"" == ""
False

$ python3 -b
>>> b"" == ""
__main__:1: BytesWarning: Comparison between bytes and string
False

$ python3 -bb
>>> b"" == ""
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
BytesWarning: Comparison between bytes and string

Индексирование байтовых объектов¶Indexing bytes objects

Еще одно потенциально удивительное изменение – это поведение индексирования байтовых объектов в Python 3:

>>> b"xyz"[0]
120

Действительно, байтовые объекты Python 3 (а также объекты bytearray) являются последовательностями целых чисел. Но код, перенесенный из Python 2, часто предполагает, что индексирование байтовой строки дает другую байтовую строку, а не целое число. Чтобы согласовать оба поведения, используйте срезы:

>>> b"xyz"[0:1]
b'x'
>>> n = 1
>>> b"xyz"[n:n+1]
b'y'

Единственная оставшаяся ловушка в том, что выход за границы при срезе возвращает пустой байтовый объект вместо возбуждения IndexError:

>>> b"xyz"[3]
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
IndexError: index out of range
>>> b"xyz"[3:4]
b''

__str__()/__unicode__()¶

В Python 2 объекты могут определять как строковое, так и unicode представление себя. В Python 3, однако, существует только строковое представление. Это становится проблемой, поскольку люди могут нечаянно делать в своих методах __str__() вещи, которые приводят к непредсказуемым результатам (например, бесконечная рекурсия, если использовать идиому unicode(self).encode('utf8') в качестве тела метода __str__()).

Есть два способа решить эту проблему. Первый – использовать пользовательский фиксер 2to3. В блоге по адресу http://lucumr.pocoo.org/2011/1/22/forwards-compatible-python/ описывается, как это сделать. Это позволит 2to3 заменить все вхождения def __unicode(self): ... на def __str__(self): .... Для этого требуется, чтобы метод __str__() был определён в Python 2 перед методом __unicode__().

Другой вариант – использовать примесь (mixin class). Это позволяет определить только метод __unicode__() для вашего класса, а примесь сама сгенерирует __str__() (код из http://lucumr.pocoo.org/2011/1/22/forwards-compatible-python/):

import sys

class UnicodeMixin(object):

  """Миксин-класс для определения правильных методов __str__/__unicode__
  методов в Python 2 или 3.

  if sys.version_info[0] >= 3: # Python 3
      def __str__(self):
          return self.__unicode__()
  else:  # Python 2
      def __str__(self):
          return self.__unicode__().encode('utf8')


class Spam(UnicodeMixin):

  def __unicode__(self):
      return u'spam-spam-bacon-spam'  # 2to3 удалит префикс 'u'.

Не индексируйте исключения¶Don’t Index on Exceptions

В Python 2 следующее работало:

>>> exc = Exception(1, 2, 3)
>>> exc.args[1]
2
>>> exc[1]  # Только Python 2!
2

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

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

Не используйте __getslice__ и компанию¶Don’t use __getslice__ & Friends

Уже некоторое время считалось устаревшим, но Python 3 наконец отказался от поддержки __getslice__() и т.д. Полностью переходите на __getitem__() и ее друзей.

Обновление doctest-ов¶Updating doctests

2to3 попытается сгенерировать исправления для доктестов, которые встретит. Однако это не идеально. Если вы написали монолитный набор доктестов (например, одну строку документации, содержащую все доктесты), стоит хотя бы рассмотреть разбивку доктестов на более мелкие части, чтобы их было легче исправлять. В противном случае может быть вполне оправданно потратить время и усилия на перенос тестов на unittest.

Обновление map для несбалансированных входных последовательностей¶Update map for imbalanced input sequences

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

В Python 3, если входные последовательности для map имеют разную длину, map остановится по достижении конца самой короткой последовательности. Для полной совместимости с map из Python 2.x оберните последовательности в itertools.zip_longest(), например: map(func, *sequences) превращается в list(map(func, itertools.zip_longest(*sequences))).

Вручную¶Manually

Чтобы вручную преобразовать исходный код с помощью 2to3, используйте сценарий 2to3, который устанавливается вместе с Python 2.6 и новее.:

2to3 <directory or file to convert>

Это заставит 2to3 вывести diff со всеми применёнными фиксерами для преобразованного исходного кода. Если вы хотите, чтобы 2to3 сразу применил изменения, передайте ему флаг -w:

2to3 -w <stuff to convert>

Доступны и другие флаги для управления тем, какие именно фиксеры применяются, и т. д.

Во время установки¶During Installation

Когда пользователь устанавливает ваш проект для Python 3, можно поручить либо distutils, либо Distribute запустить 2to3 от вашего имени. Для distutils используйте следующий шаблон:

try:  # Python 3
  from distutils.command.build_py import build_py_2to3 as build_py
except ImportError:  # Python 2
  from distutils.command.build_py import build_py

setup(cmdclass = {'build_py': build_py},
  # ...
)

Для Distribute:

setup(use_2to3=True,
  # ...
)

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