Что нового в Python 3.0

Автор:Гвидо ван Россумом

В этой статье объясняются новые возможности Python 3.0 по сравнению с 2.6. Python 3.0, также известный как «Python 3000» или «Py3K», является первым выпуском Python намеренно обратно несовместимым. Изменений больше, чем в обычном выпуске, и больше важных для всех пользователей Python. Тем не менее, проанализировав изменения, вы обнаружите, что Python на самом деле изменился не так уж сильно — по большому счёту, мы в основном исправим хорошо известные недостатки и недочёты и удалим много старого хлама.

В этой статье не делается попытка предоставить полную спецификацию всех новых функций, а вместо этого делается попытка дать удобный обзор. Для получения полной информации вам следует обратиться к документации по Python 3.0 и/или множеству PEP, на которые есть ссылки в тексте. Если вы хотите понять полную реализацию и обоснование дизайна для функции, PEP обычно содержат больше деталей, чем обычная документация; но обратите внимание, что PEP обычно не обновляются после того, как функция полностью реализована.

Из-за нехватки времени данный документ не настолько полный, как должен был быть. Как всегда для новой версии, файл Misc/NEWS в исходном дистрибутиве содержит множество подробной информации о каждой мелочи, которая была изменена.

Общие камни преткновения

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

print — это функция

Оператор print был заменён функцией print() с ключевыми аргументами, чтобы заменить большую часть специального синтаксиса старого оператора print (PEP 3105). Примеры:

Old: print "The answer is", 2*2
New: print("The answer is", 2*2)

Old: print x,           # Завершающая запятая подавляет новую строку
New: print(x, end=" ")  # Добавляет пробел вместо новой строки

Old: print              # Печатает новую строку
New: print()            # Вы должны вызвать функцию!

Old: print >>sys.stderr, "fatal error"
New: print("fatal error", file=sys.stderr)

Old: print (x, y)       # печатает repr((x, y))
New: print((x, y))      # Не то же самое, что print(x, y)!

Вы также можете настроить разделитель между элементами, например

print("There are <", 2**32, "> possibilities!", sep="")

который производит:

There are <4294967296> possibilities!

Примечание:

  • Функция print() не поддерживает функцию «softspace» старого оператора print. Например, в Python 2.x print "A\n", "B" будет выглядеть как "A\nB\n"; но в Python 3.0 print("A\n", "B") напишет "A\n B\n".
  • Сначала вы обнаружите, что много набираете по старому print x в интерактивном режиме. Пора переучить пальцы набирать print(x) вместо этого!
  • При использовании инструмента преобразования исходного кода 2to3 все операторы print автоматически преобразуются в вызовы функций print(), поэтому для крупных проектов это обычно не проблема.

Представления и итераторы вместо списков

Некоторые известные API больше не возвращают списки:

  • Методы dict dict.keys(), dict.items() и dict.values() возвращают «представления» вместо списков. Например, это больше не работает: k = d.keys(); k.sort(). Вместо этого используйте k = sorted(d) (это работает и в Python 2.5 и столь же эффективно).

  • Кроме того, больше не поддерживаются методы dict.iterkeys(), dict.iteritems() и dict.itervalues().

  • map() и filter() возвращают итераторы. Если вам действительно нужен список и все входные последовательности имеют одинаковую длину, быстрое исправление состоит в том, чтобы обернуть map() в list(), например. list(map(...)), но лучше часто использовать списковое включение (особенно когда в исходном коде используется lambda) или переписать код, чтобы ему вообще не требовался список. Особенно сложно map() вызывается из-за побочных эффектов функции; правильным преобразованием является использование обычного цикла for (поскольку создание списка было бы просто расточительным).

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

  • range() теперь ведёт себя так же, как xrange(), за исключением того, что она работает со значениями произвольного размера. Последней больше нет.

  • zip() теперь возвращает итератор.

Сравнение сортировок

Python 3.0 упростил правила упорядочивания сравнений:

  • Операторы сравнения порядка (<, <=, >=, >) вызывают исключение TypeError, когда операнды не имеют значимого естественного порядка. Таким образом, такие выражения, как 1 < '', 0 > None или len <= len, больше недействительны, и, например. None < None вызывает TypeError вместо возврата False. Следствием этого является то, что сортировка разнородного списка больше не имеет смысла — все элементы должны быть сопоставимы друг с другом. Обратите внимание, что это не относится к операторам == и !=: объекты разных несравнимых типов всегда сравниваются неравными друг другу.
  • builtin.sorted() и list.sort() больше не принимают аргумент cmp, предоставляющий функцию сравнения. Вместо этого используйте аргумент key. Н.Б. аргументы key и reverse теперь являются «только ключевыми».
  • Функцию cmp() следует считать устаревшей, а специальный метод __cmp__() больше не поддерживается. Используйте __lt__() для сортировки, __eq__() с __hash__() и другие расширенные сравнения по мере необходимости. (Если вам действительно нужна функциональность cmp(), вы можете использовать выражение (a > b) - (a < b) как эквивалент cmp(a, b).)

Целые числа

  • PEP 237: long переименован в int. Т. е. имеется только один встроенный целочисленный тип с именем int; но в основном он ведёт себя как старый тип long.
  • PEP 238: выражение вроде 1/2 возвращает число с плавающей запятой. Используйте 1//2, чтобы получить поведение усечения. (Последний синтаксис существует уже много лет, по крайней мере, с Python 2.2.)
  • Константа sys.maxint была удалена, т. к. больше нет ограничения на значение целых чисел. Однако sys.maxsize можно использовать как целое число, большее, чем любой практичный список или строковый индекс. Он соответствует «естественному» целочисленному размеру реализации и обычно совпадает с sys.maxint в предыдущих выпусках на той же платформе (при тех же параметрах сборки).
  • repr() длинного целого числа больше не включает конечный L, поэтому код, который безоговорочно удаляет данный символ, вместо этого отрезает последнюю цифру. (Вместо этого используйте str().)
  • Восьмеричные литералы больше не имеют формы 0720; вместо этого используйте 0o720.

Текст против Данных вместо Юникода против 8-бит

Всё, что вы думали, что знаете о двоичных данных и Юникод, изменилось.

  • Python 3.0 использует концепции text и (двоичный) data вместо строк Юникод и 8-битных строк. Весь текст в Юникоде; однако encoded Юникод представлен в виде двоичных данных. Для хранения текста используется тип str, для хранения данных используется тип bytes. Самая большая разница с ситуацией 2.x заключается в том, что любая попытка смешать текст и данные в Python 3.0 вызывает TypeError, тогда как если бы смешивался Юникод и 8-битные строки в Python 2.x, это сработало бы, если бы 8-битный строка содержала только 7-битные (ASCII) байты и будет получено UnicodeDecodeError, если она содержала отличные от ASCII значения. Такое ценностно-ориентированное поведение на протяжении многих лет вызывало множество грустных лиц.
  • Как следствие этого изменения в философии, почти весь код, использующий Юникод, кодировки или двоичные данные, скорее всего, должен измениться. Изменения к лучшему, т. к. в мире 2.x было множество ошибок, связанных с смешиванием закодированного и незакодированного текста. Чтобы подготовиться к работе с Python 2.x, начните использовать unicode для всего незакодированного текста и str только для двоичных или закодированных данных. Тогда инструмент 2to3 сделает за вас большую часть работы.
  • Вы больше не можете использовать литералы u"..." для Юникод текста. Однако для двоичных данных необходимо использовать литералы b"...".
  • Поскольку типы str и bytes нельзя смешивать, вы всегда должны явно преобразовывать их. Используйте str.encode(), чтобы перейти от str к bytes, и bytes.decode(), чтобы перейти от bytes к str. Вы также можете использовать bytes(s, encoding=...) и str(b, encoding=...) соответственно.
  • Как и str, тип bytes является неизменяемым. Существует отдельный изменчивый тип для хранения буферизованных двоичных данных, bytearray. Почти все API, которые принимают bytes, также принимают bytearray. Изменяемый API основан на collections.MutableSequence.
  • Все обратные косые черты в необработанных строковых литералах интерпретируются буквально. Это означает, что escape-последовательности '\U' и '\u' в необработанных строках не обрабатываются особым образом. Например, r'\u20ac' — это строка из 6 символов в Python 3.0, тогда как в версии 2.6 ur'\u20ac' был единственным символом «евро». (Конечно, это изменение влияет только на необработанные строковые литералы; символ евро — '\u20ac' в Python 3.0.)
  • Встроенный абстрактный тип basestring был удалён. Вместо него используйте str. Типы str и bytes не имеют достаточно общих функциональных возможностей, чтобы гарантировать общий базовый класс. Инструмент 2to3 (см. ниже) заменяет каждое вхождение basestring на str.
  • Файлы, открытые как текстовые файлы (все ещё режим по умолчанию для open()), всегда используют кодировку для сопоставления между строками (в памяти) и байтами (на диске). Двоичные файлы (открытые с b в аргументе режима) всегда используют байты в памяти. Это означает, что если файл открывается с использованием неправильного режима или кодировки, ввод-вывод, скорее всего, будет громко давать сбой, вместо того, чтобы молча создавать неверные данные. Это также означает, что даже пользователи Unix должны будут указать правильный режим (текстовый или двоичный) при открытии файла. Существует кодировка по умолчанию, зависящая от платформы, которая на платформах Unixy может быть установлена с помощью переменной среды LANG (а иногда также с некоторыми другими переменными среды, связанными с локалью, зависящей от платформы). Во многих случаях, но не во всех, по умолчанию используется кодировка UTF-8; вы никогда не должны рассчитывать на это значение по умолчанию. Любое приложение, читающее или пишущее больше, чем чистый текст ASCII, вероятно, должно иметь способ переопределить кодировку. Больше нет необходимости использовать потоки с поддержкой кодирования в модуле codecs.
  • Исходные значения sys.stdin, sys.stdout и sys.stderr теперь являются текстовыми файлами только в Юникоде (т. е. они являются экземплярами io.TextIOBase). Чтобы читать и записывать данные байтов с этими потоками, вам нужно использовать их атрибут io.TextIOBase.buffer.
  • Имена файлов передаются в API и возвращаются из них в виде строк (Юникод). Это может привести к проблемам, связанным с платформой, поскольку на некоторых платформах имена файлов представляют собой произвольные строки байтов. (С другой стороны, в Windows имена файлов изначально хранятся в формате Юникод.) В качестве обходного пути большинство API (например, open() и многие функции в модуле os), которые принимают имена файлов, принимают объекты bytes, а также строки, и несколько API есть способ запросить возвращаемое значение bytes. Таким образом, os.listdir() возвращает список экземпляров bytes, если аргументом является экземпляр bytes, а os.getcwdb() возвращает текущий рабочий каталог как экземпляр bytes. Обратите внимание, что когда os.listdir() возвращает список строк, имена файлов, которые не могут быть правильно декодированы, опускаются, а не вызывают UnicodeError.
  • Некоторые системные API os.environ и sys.argv, также могут создавать проблемы, когда предоставляемые системой байты, не интерпретируются с использованием кодировки по умолчанию. Установка переменной LANG и повторный запуск программы, вероятно, лучший подход.
  • PEP 3138: repr() строки больше не экранирует символы, отличные от ASCII. Однако он по-прежнему экранирует управляющие символы и кодовые точки с непечатаемым статусом в Юникод стандарте.
  • PEP 3120: исходная кодировка по умолчанию теперь UTF-8.
  • PEP 3131: в идентификаторах теперь разрешены буквы, отличные от ASCII. (Однако стандартная библиотека остаётся только для ASCII, за исключением имён участников в комментариях.)
  • Модули StringIO и cStringIO исчезли. Вместо этого импортировать модуль io и используйте io.StringIO или io.BytesIO для текста и данных соответственно.
  • См. также HOWTO по Юникоду, который был обновлён для Python 3.0.

Обзор изменений синтаксиса

В этом разделе дается краткий обзор каждого изменения синтаксиса в Python 3.0.

Новый синтаксис

  • PEP 3107: аннотации аргумента функции и возвращаемого значения. Это обеспечивает стандартизированный способ аннотирования параметров функции и возвращаемого значения. К таким аннотациям не привязана семантика, за исключением того, что их можно исследовать во время выполнения с помощью атрибута __annotations__. Цель состоит в том, чтобы поощрять эксперименты с помощью метаклассов, декораторов или фреймворков.

  • PEP 3102: Только ключевые аргументы. Именованные параметры, встречающиеся после *args в списке параметров должны указываться с использованием синтаксиса ключевого аргумента в вызове. Вы также можете использовать голый * в списке параметров, чтобы указать, что вы не принимаете список аргументов переменной длины, но у вас есть только ключевые аргументы.

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

  • PEP 3104: оператор nonlocal. Используя nonlocal x, теперь вы можете напрямую назначать переменную во внешней (но не глобальной) области. nonlocal — новое зарезервированное слово.

  • PEP 3132: расширенная итерируемая распаковка. Теперь вы можете писать такие вещи, как a, b, *rest = some_sequence. И даже *rest, a = stuff. Объект rest всегда представляет собой (возможно, пустой) список; правая часть может быть любой итерируемой. Пример:

    (a, *rest, b) = range(5)

    Это устанавливает a в 0, b в 4 и rest в [1, 2, 3].

  • Словарное включение: {k: v for k, v in stuff} означает то же самое, что и dict(stuff), но является более гибким. (Это PEP 274 подтверждено. :-)

  • Устанавливает литералы, например. {1, 2}. Обратите внимание, что {} — это пустой словарь; используйте set() для пустого множества. Также поддерживаются комплексные включения; например, {x for x in stuff} означает то же самое, что и set(stuff), но является более гибким.

  • Новые восьмеричные литералы, например. 0o720 (уже в 2.6). Старые восьмеричные литералы (0720) исчезли.

  • Новые двоичные литералы, например. 0b1010 (уже в 2.6), и есть новая соответствующая встроенная функция, bin().

  • Байтовые литералы вводятся с начальным b или B, и есть новая соответствующая встроенная функция, bytes().

Изменённый синтаксис

  • PEP 3109 и PEP 3134: новый синтаксис оператора raise: raise [expr [from expr]]. Смотри ниже.

  • as и with теперь являются зарезервированными словами. (Начиная с 2.6, на самом деле.)

  • True, False и None являются зарезервированными словами. (2.6 уже частично ввела ограничения на None.)

  • Изменение с except exc, var на except exc as var. См. PEP 3110.

  • PEP 3115: новый синтаксис метакласса. Вместо:

    class C:
    __metaclass__ = M
    ...

    теперь вы должны использовать:

    class C(metaclass=M):
    ...

    Глобальная переменная модуля __metaclass__ больше не поддерживается. (Это был костыль, чтобы упростить использование по умолчанию классов нового стиля без наследования каждого класса от object.)

  • Включение списков больше не поддерживает синтаксическую форму [... for var in item1, item2, ...]. Вместо этого используйте [... for var in (item1, item2, ...)]. Также обратите внимание, что списковые включения имеют другую семантику: они ближе к синтаксическому сахару для выражения генератора внутри конструктора list(), и, в частности, переменные управления циклом больше не просачиваются в окружающую область.

    многоточие (...) можно использовать как атомарное выражение где угодно. (Ранее это было разрешено только в виде фрагментов.) Кроме того, оно должно записываться как .... (Ранее его также можно было записать как . . . по простой грамматической случайности.)

Удалённый синтаксис

  • PEP 3113: удалена распаковка параметров кортежа. Вы больше не можете писать def foo(a, (b, c)): .... Вместо этого используйте def foo(a, b_c): b, c = b_c.
  • Удалены обратные кавычки (вместо них используйте repr()).
  • Удалён <> (вместо него используйте !=).
  • Удалён ключевой аргумент: exec() больше не является ключевым; она остаётся как функция. (К счастью, синтаксис функции также был принят в 2.x.) Также обратите внимание, что exec() больше не принимает потоковый аргумент; вместо exec(f) можно использовать exec(f.read()).
  • Целочисленные литералы больше не поддерживают конечный l или L.
  • Строковые литералы больше не поддерживают начальный u или U.
  • Синтаксис from module import * разрешён только на уровне модуля, а не внутри функций.
  • Единственный приемлемый синтаксис для относительного импорта — from .[module] import name. Все формы import, не начинающиеся с ., интерпретируются как абсолютный импорт. (PEP 328)
  • Классические классы исчезли.

Изменения, уже присутствующие в Python 2.6

Поскольку многие пользователи, по-видимому, сразу переходят с Python 2.5 на Python 3.0, данный раздел напоминает читателю о новых функциях, которые изначально были разработаны для Python 3.0, но были перенесены обратно в Python 2.6. Подробные описания см. в соответствующих разделах Что нового в Python 2.6.

Изменения в библиотеке

Из-за нехватки времени данный документ не охватывает исчерпывающим образом очень обширные изменения в стандартной библиотеке. PEP 3108 — это ссылка на основные изменения в библиотеке. Вот обзор капсул:

  • Многие старые модули были удалены. gopherlib больше не используется и md5 заменен на hashlib, уже устарели в PEP 4. Другие были удалены в результате прекращения поддержки различных платформ, например, Irix, BeOS и Mac OS 9 (см. PEP 11). Некоторые модули также были выбраны для удаления в Python 3.0 из-за неиспользования или из-за того, что существует лучшая замена. Полный список см. в PEP 3108.

  • Пакет bsddb3 был удалён, т. к. его присутствие в базовой стандартной библиотеке со временем стало особенно обременительным для основных разработчиков из-за нестабильности тестирования и графика релиза Berkeley DB. Тем не менее, пакет жив и здоров, внешне поддерживается по адресу.

  • Некоторые модули были переименованы, потому что их старое имя не соответствовало PEP 8 или по другим причинам. Вот список:

    Старое имя Новое имя
    _winreg winreg
    ConfigParser configparser
    copy_reg copyreg
    Queue queue
    SocketServer socketserver
    markupbase _markupbase
    repr reprlib
    test.test_support test.support

  • Обычный шаблон в Python 2.x состоит в том, чтобы иметь одну версию модуля, реализованную на чистом Python, с дополнительной ускоренной версией, реализованной как расширение C; например, pickle и cPickle. Это возлагает бремя импорта ускоренной версии и возврата к чистой версии Python на каждого пользователя данных модулей. В Python 3.0 ускоренные версии считаются деталями реализации чистых версий Python. Пользователи всегда должны импортировать стандартную версию, которая пытается импортировать ускоренную версию и возвращается к чистой версии Python. Пара pickle/cPickle подверглась такой обработке. Модуль profile есть в списке для 3.1. Модуль StringIO был преобразован в класс в модуле io.

  • Некоторые связанные модули были сгруппированы в пакеты, и обычно имена подмодулей были упрощены. Полученные новые пакеты:

    • dbm (anydbm, dbhash, dbm, dumbdbm, gdbm, whichdb).
    • html (HTMLParser, htmlentitydefs).
    • http (httplib, BaseHTTPServer, CGIHTTPServer, SimpleHTTPServer, Cookie, cookielib).
    • tkinter (все модули, относящиеся к Tkinter, кроме turtle). Целевой аудитории turtle на самом деле нет дела до tkinter. Также обратите внимание, что в Python 2.6 функциональность turtle была значительно расширена.
    • urllib (urllib, urllib2, urlparse, robotparse).
    • xmlrpc (xmlrpclib, DocXMLRPCServer, SimpleXMLRPCServer).

Некоторые другие изменения в модулях стандартной библиотеки, не предусмотренные PEP 3108:

  • Убит sets. Используйте встроенный класс set().
  • Очистка модуля sys: удалены sys.exitfunc(), sys.exc_clear(), sys.exc_type, sys.exc_value, sys.exc_traceback. (Обратите внимание, что sys.last_type и т. д. остаются.)
  • Очистка типа array.array: методы read() и write() убраны; вместо этого используйте fromfile() и tofile(). Кроме того, код типа 'c' для массива больше не используется — используйте либо 'b' для байтов, либо 'u' для символов Юникода.
  • Очистка модуля operator: удалены sequenceIncludes() и isCallable().
  • Очистка модуля thread: acquire_lock() и release_lock() удалены; вместо этого используйте acquire() и release().
  • Очистка модуля random: удалён API jumpahead().
  • Модуль new исчез.
  • Функции os.tmpnam(), os.tempnam() и os.tmpfile() были удалены в пользу модуля tempfile.
  • Модуль tokenize изменён для работы с байтами. Основная точка входа теперь tokenize.tokenize() вместо generate_tokens.
  • string.letters и его друзья (string.lowercase и string.uppercase) исчезли. Вместо этого используйте string.ascii_letters и т. д. (Причина удаления в том, что string.letters и его друзья имели поведение, зависящее от локали, что является плохой идеей для таких глобальных «констант» с привлекательными именами.)
  • Модуль переименован __builtin__ в builtins (удалены символы подчеркивания, добавлена буква «s»). Переменная __builtins__, присутствующая в большинстве глобальных пространств имён, не изменилась. Чтобы изменить встроенную функцию, вы должны использовать builtins, а не __builtins__!

PEP 3101: новый подход к форматированию строк

  • Новая система встроенных операций форматирования строк заменяет оператор форматирования строк %. (Тем не менее, оператор % по-прежнему поддерживается; он будет объявлен устаревшим в Python 3.1 и будет удалён из языка позднее.) Прочитайте PEP 3101, чтобы получить полную информацию.

Изменения в исключениях

API-интерфейсы для создания и перехвата исключений были очищены и добавлены новые мощные функции:

  • PEP 352: все исключения должны быть производными (прямо или косвенно) от BaseException. Это корень иерархии исключений. Это не новая рекомендация, но требование для наследования от BaseException является новым. (Python 2.6 по-прежнему позволял вызывать классические классы и не налагал ограничений на то, что вы можете перехватывать.) Как следствие, строковые исключения, наконец, действительно и полностью мертвы.

  • Почти все исключения должны происходить из Exception; BaseException следует использовать только в качестве базового класса для исключений, которые должны обрабатываться только на верхнем уровне, например SystemExit или KeyboardInterrupt. Рекомендуемая идиома для обработки всех исключений, кроме этой последней категории, заключается в использовании except Exception.

  • StandardError был удалён.

  • Исключения больше не ведут себя как последовательности. Вместо этого используйте атрибут args.

  • PEP 3109: создание исключений. Теперь вы должны использовать raise Exception(args) вместо raise Exception, args. Кроме того, вы больше не можете явно указывать трассировку; вместо этого, если вы have для этого, вы можете напрямую назначить атрибут __traceback__ (см. ниже).

  • PEP 3110: Перехват исключений. Теперь вы должны использовать except SomeException as variable вместо except SomeException, variable. Более того, variable явно удаляется, когда остаётся блок except.

  • PEP 3134: Цепочка исключений. Есть два случая: неявная цепочка и явная цепочка. Неявная цепочка возникает, когда в блоке обработчика except или finally возникает исключение. Обычно это происходит из-за ошибки в блоке обработчика; мы называем это исключением secondary. В этом случае исходное исключение (обрабатываемое) сохраняется как атрибут __context__ вторичного исключения. С помощью этого синтаксиса вызывается явная цепочка:

    raise SecondaryException() from primary_exception

    (где primary_exception — любое выражение, создающее объект-исключение, возможно, ранее перехваченное исключение). В этом случае основное исключение сохраняется в атрибуте __cause__ вторичного исключения. Обратная трассировка, выводимая при возникновении необработанного исключения, проходит по цепочке атрибутов __cause__ и __context__ и печатает отдельную трассировку для каждого компонента цепочки, при этом основное исключение находится вверху. (Пользователи Java могут распознать это поведение.)

  • PEP 3134: объекты исключений теперь сохраняют свою трассировку как атрибут __traceback__. Это означает, что объект исключения теперь содержит всю информацию, относящуюся к исключению, и причин для использования sys.exc_info() стало меньше (хотя последний не удален).

  • Улучшено несколько сообщений об исключениях, когда Windows не удается загрузить модуль расширения. Например, error code 193 теперь %1 is not a valid Win32 application. Строки теперь имеют дело с неанглийскими локалями.

Прочие изменения

Операторы и специальные методы

  • != теперь возвращает результат, противоположный ==, если == не возвращает NotImplemented.
  • Концепция «несвязанных методов» была удалена из языка. При ссылке на метод как на атрибут класса теперь вы получаете простой объект функции.
  • __getslice__(), __setslice__() и __delslice__() были убиты. Синтаксис a[i:j] теперь преобразуется в a.__getitem__(slice(i, j)) (или __setitem__() или __delitem__() при использовании в качестве цели назначения или удаления соответственно).
  • PEP 3114: стандартный метод next() был переименован в __next__().
  • Специальные методы __oct__() и __hex__() удалены — oct() и hex() теперь используют __index__() для преобразования аргумента в целое число.
  • Удалена поддержка __members__ и __methods__.
  • Атрибуты функций с именем func_X были переименованы, чтобы использовать форму __X__, освобождая данные имена в пространстве имён атрибутов функций для определяемых пользователем атрибутов. А именно, func_closure, func_code, func_defaults, func_dict, func_doc, func_globals, func_name были переименованы в __closure__, __code__, __defaults__, __dict__, __doc__, __globals__, __name__, соответственно.
  • __nonzero__() теперь __bool__().

Встроенные

  • PEP 3135: новый super(). Теперь вы можете вызывать super() без аргументов, и (при условии, что это обычный метод экземпляра, определённый внутри оператора class) автоматически будут выбраны правильный класс и экземпляр. С аргументами поведение super() не изменилось.
  • PEP 3111: raw_input() был переименован в input(). Т. е. новая функция input() считывает строку из sys.stdin и возвращает её с удаленной завершающей строкой новой строки. Он вызывает EOFError, если ввод завершается преждевременно. Чтобы получить старое поведение input(), используйте eval(input()).
  • Добавлена новая встроенная функция next() для вызова метода __next__() для объекта.
  • Стратегия округления функции round() и тип возвращаемого значения изменились. Точные промежуточные случаи теперь округляются до ближайшего четного результата, а не от нуля. (Например, round(2.5) теперь возвращает 2, а не 3.) round(x[, n]) теперь делегирует x.__round__([n]) вместо того, чтобы всегда возвращать число с плавающей запятой. Обычно он возвращает целое число при вызове с одним аргументом и значение того же типа, что и x, при вызове с двумя аргументами.
  • intern() перемещён в sys.intern().
  • Удалено: apply(). Вместо apply(f, args) используйте f(*args).
  • Удалена callable(). Вместо callable(f) можно использовать isinstance(f, collections.Callable). Функция operator.isCallable() также исчезла.
  • Удалена coerce(). Данная функция больше не служит цели, поскольку классические классы ушли.
  • Удалена execfile(). Вместо execfile(fn) используйте exec(open(fn).read()).
  • Удалён тип file. Используйте open(). Теперь в модуле io есть несколько различных типов открытых потоков.
  • Удалена reduce(). Используйте functools.reduce(), если вам это действительно нужно; однако в 99% случаев явный цикл for более удобочитаем.
  • Удалена reload(). Используйте imp.reload().
  • Удалён dict.has_key() – вместо него используйте оператор in.

Изменения сборки и C API

Из-за нехватки времени здесь представлен неполный список самых важных изменений в C API.

  • Поддержка нескольких платформ была прекращена, включая, помимо прочего, Mac OS 9, BeOS, RISCOS, Irix и Tru64.
  • PEP 3118: новый API буфера.
  • PEP 3121: Инициализация и завершение модуля расширения.
  • PEP 3123: приведение PyObject_HEAD в соответствие со стандартом C.
  • Больше нет поддержки C API для ограниченного выполнения.
  • PyNumber_Coerce(), PyNumber_CoerceEx(), PyMember_Get() и PyMember_Set() C API удалены.
  • Новый C API PyImport_ImportModuleNoBlock() работает как PyImport_ImportModule(), но не блокирует блокировку импорта (вместо этого возвращает ошибку).
  • Переименован слот и метод логического преобразования уровня C: nb_nonzero теперь nb_bool.
  • Удалены METH_OLDARGS и WITH_CYCLE_GC из C API.

Производительность

Конечным результатом обобщений 3.0 является то, что Python 3.0 выполняет тест pystone примерно на 10% медленнее, чем Python 2.5. Скорее всего, самой главной причиной является удаление специального регистра для небольших целых чисел. Есть возможности для улучшения, но это произойдет после выхода версии 3.0!

Портирование на Python 3.0

Для переноса существующего исходного кода 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, так и на Python 3.0; вам придётся использовать очень искаженный стиль кодирования, например, избегая операторов print, метаклассов и многого другого. Если вы поддерживаете библиотеку, которая должна поддерживать как Python 2.6, так и Python 3.0, лучше всего изменить шаг 3 выше, отредактировав версию исходного кода 2.6 и снова запустив транслятор 2to3, а не редактируя версию 3.0 исходный код.

Информацию о переносе расширений C на Python 3.0 см. в статье Перенос модулей расширения на Python 3.