Документация Python неофициальный перевод
Содержание страницы

Что нового в Python 3.0What’s New In Python 3.0

Автор:

Guido van Rossum

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

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

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

Типичные проблемыCommon Stumbling Blocks

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

Представления и итераторы вместо списковViews And Iterators Instead Of Lists

Некоторые известные 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() теперь возвращает итератор.

Сравнения на упорядочиваниеOrdering Comparisons

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

  • Операторы сравнения на упорядочивание (<, <=, >=, >) вызывают исключение TypeError, если операнды не имеют осмысленного естественного порядка. Таким образом, выражения вроде 1 < '', 0 > None или len <= len больше не допустимы, и, например, None < None вызывает TypeError вместо возврата False. Следствием является то, что сортировка гетерогенного списка больше не имеет смысла – все элементы должны быть сравнимы друг с другом. Обратите внимание, что это не относится к операторам == и !=: объекты разных несравнимых типов всегда считаются неравными друг другу.

  • sorted() и list.sort() больше не принимают аргумент cmp, задающий функцию сравнения. Вместо него используйте аргумент key. Примечание: аргументы key и reverse теперь являются только ключевыми (keyword-only).

  • Функция cmp() должна считаться исчезнувшей, а специальный метод __cmp__() больше не поддерживается. Используйте __lt__() для сортировки, __eq__() с __hash__() и другие расширенные сравнения по необходимости. (Если действительно нужна функциональность cmp(), можно использовать выражение (a > b) - (a < b) как эквивалент cmp(a, b).)

Целые числаIntegers

  • 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 вместо этого.

Текст и данные вместо Unicode и 8-битных строкText Vs. Data Instead Of Unicode Vs. 8-bit

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

  • Python 3.0 использует понятия текста и (двоичных) данных вместо строк Unicode и 8-битных строк. Весь текст – это Unicode; однако закодированный Unicode представляется в виде двоичных данных. Типом для хранения текста является str, типом для хранения данных – bytes. Самое большое отличие от ситуации в 2.x заключается в том, что любая попытка смешать текст и данные в Python 3.0 приводит к TypeError, тогда как при смешивании Unicode и 8-битных строк в Python 2.x код работал, если 8-битная строка содержала только 7-битные (ASCII) байты, но возникало UnicodeDecodeError, если в ней были не-ASCII значения. Такое поведение, зависящее от значения, вызывало множество огорчений на протяжении многих лет.

  • Как следствие этого изменения в философии, практически весь код, работающий с Unicode, кодировками или двоичными данными, скорее всего, придётся изменить. Это изменение к лучшему, так как в мире 2.x было множество ошибок, связанных со смешиванием закодированного и незакодированного текста. Чтобы подготовиться в Python 2.x, начните использовать unicode для всего незакодированного текста, а str – только для двоичных или закодированных данных. Тогда инструмент 2to3 сделает большую часть работы за вас.

  • Больше нельзя использовать литералы u"..." для текста Unicode. Однако для двоичных данных необходимо использовать литералы 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.

  • Все обратные слеши в сырых строковых литералах интерпретируются буквально. Это означает, что последовательности '\U' и '\u' в сырых строках не обрабатываются особым образом. Например, r'\u20ac' в Python 3.0 – это строка из 6 символов, тогда как в 2.6 ur'\u20ac' был одним символом «евро». (Разумеется, это изменение затрагивает только сырые строковые литералы; символ евро в Python 3.0 – это '\u20ac'.)

  • Встроенный абстрактный тип basestring был удалён. Используйте str вместо него. Типы str и bytes не имеют достаточной общности функциональности, чтобы оправдать общий базовый класс. Инструмент 2to3 (см. ниже) заменяет каждое вхождение basestring на str.

  • Файлы, открытые как текстовые (по-прежнему режим по умолчанию для open()), всегда используют кодировку для преобразования между строками (в памяти) и байтами (на диске). Двоичные файлы (открытые с b в аргументе режима) всегда используют байты в памяти. Это означает, что если файл открыт с неправильным режимом или кодировкой, ввод-вывод, скорее всего, приведёт к явной ошибке, а не к незаметному получению некорректных данных. Это также означает, что даже пользователи Unix должны указывать правильный режим (текстовый или двоичный) при открытии файла. Существует зависимая от платформы кодировка по умолчанию, которая на Unix-подобных платформах может быть задана с помощью переменной окружения LANG (а иногда и с помощью некоторых других платформозависимых переменных, связанных с локалью). Во многих случаях, но не во всех, системная кодировка по умолчанию – UTF-8; на неё никогда не следует полагаться. Любое приложение, читающее или записывающее нечто большее, чем чистый ASCII-текст, вероятно, должно иметь способ переопределить кодировку. Больше нет необходимости использовать потоки, поддерживающие кодировку, из модуля codecs.

  • Начальные значения sys.stdin, sys.stdout и sys.stderr теперь являются текстовыми файлами, предназначенными только для Unicode (т.е. они являются экземплярами io.TextIOBase). Для чтения и записи байтовых данных с помощью этих потоков необходимо использовать их атрибут io.TextIOBase.buffer.

  • Имена файлов передаются в API и возвращаются из них в виде строк (Unicode). Это может вызывать платформозависимые проблемы, поскольку на некоторых платформах имена файлов представляют собой произвольные байтовые строки. (С другой стороны, в Windows имена файлов изначально хранятся как Unicode.) В качестве обходного решения большинство 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 символы. Однако он по-прежнему экранирует управляющие символы и кодовые точки, имеющие статус непечатаемых в стандарте Unicode.

  • PEP 3120: Теперь кодировка исходного кода по умолчанию – UTF-8.

  • PEP 3131: Теперь в идентификаторах допускаются не-ASCII буквы. (Однако стандартная библиотека остаётся ASCII-only, за исключением имён участников в комментариях.)

  • Модули StringIO и cStringIO удалены. Вместо этого импортируйте модуль io и используйте io.StringIO или io.BytesIO для текста и данных соответственно.

  • См. также Unicode HOWTO, который был обновлён для Python 3.0.

Обзор синтаксических измененийOverview Of Syntax Changes

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

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

  • 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().

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

  • 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(), и, в частности, переменные цикла больше не просачиваются в окружающую область видимости.

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

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

  • 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.6Changes Already Present In Python 2.6

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

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

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

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

  • Пакет bsddb3 был удалён, потому что его присутствие в основной стандартной библиотеке со временем оказалось особо обременительным для основных разработчиков из-за нестабильности тестирования и графика выпуска Berkeley DB. Однако пакет жив и здоров, он поддерживается внешне по адресу https://www.jcea.es/programacion/pybsddb.htm.

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

    Старое название

    Новое название

    _winreg

    winreg

    ConfigParser

    configparser

    copy_reg

    copyreg

    очередь

    очередь

    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' для array удален – используйте 'b' для байтов или 'u' для символов Unicode.

  • Очистка модуля 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: Новый подход к форматированию строкPEP 3101: A New Approach To String Formatting

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

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

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

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

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

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

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

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

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

  • PEP 3134: Цепочки исключений. Есть два случая: неявное и явное связывание. Неявное связывание происходит, когда исключение возбуждается в блоке обработчика except или finally. Обычно это происходит из-за ошибки в блоке обработчика; мы называем это вторичным исключением. В этом случае исходное исключение (которое обрабатывалось) сохраняется как атрибут __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. Строки теперь работают с неанглийскими локалями.

Разные другие измененияMiscellaneous Other Changes

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

  • != теперь возвращает противоположность ==, если только == не возвращает 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__().

Встроенные функцииBuiltins

  • 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]) вместо того, чтобы всегда возвращать float. В общем случае она возвращает целое число при вызове с одним аргументом и значение того же типа, что и 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(). Теперь существует несколько различных видов потоков, которые open может возвращать в модуле io.

  • Удалён reduce(). Используйте functools.reduce(), если он действительно нужен; однако в 99% случаев явный цикл for читается лучше.

  • Удалён reload(). Используйте imp.reload().

  • Удалено. dict.has_key() – вместо этого используйте оператор in.

Изменения в сборке и C APIBuild and C API Changes

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

  • Поддержка нескольких платформ прекращена, включая, но не ограничиваясь Mac OS 9, BeOS, RISCOS, Irix и Tru64.

  • PEP 3118: Новый буферный API.

  • PEP 3121: Инициализация и финализация модулей расширения.

  • PEP 3123: Приведение PyObject_HEAD в соответствие со стандартом C.

  • Больше нет поддержки C API для ограниченного выполнения.

  • C API PyNumber_Coerce(), PyNumber_CoerceEx(), PyMember_Get() и PyMember_Set() удалены.

  • Новый C API PyImport_ImportModuleNoBlock(), работает как PyImport_ImportModule(), но не блокируется на блокировке импорта (вместо этого возвращается ошибка).

  • Переименован слот и метод уровня C для преобразования в логическое значение: nb_nonzero теперь nb_bool.

  • Из C API удалены METH_OLDARGS и WITH_CYCLE_GC.

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

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

Перенос на Python 3.0Porting To 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 над вашим деревом исходного кода. Запустите результат трансляции в Python 3.0. Вручную исправьте все оставшиеся проблемы, устраняя неполадки, пока все тесты снова не будут проходить.

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

По вопросам переноса расширений на C в Python 3.0 обратитесь к разделу Перенос модулей расширений на Python 3.