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

Print – функция¶Print Is A Function

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

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

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

• Методы dict: dict.keys(), dict.items() и dict.values() теперь возвращают «представления» (views) вместо списков. Например, это больше не работает: 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 упростил правила для сравнений на упорядочивание:

• The ordering comparison operators (<, <=, >=, >) raise a TypeError exception when the operands don’t have a meaningful natural ordering. Thus, expressions like 1 < '', 0 > None or len <= len are no longer valid, and e.g. None < None raises TypeError instead of returning False. A corollary is that sorting a heterogeneous list no longer makes sense – all the elements must be comparable to each other. Note that this does not apply to the == and != operators: objects of different incomparable types always compare unequal to each other.
• builtin.sorted() и list.sort() больше не принимают аргумент cmp, задающий функцию сравнения. Вместо него используйте аргумент key. Примечание: аргументы key и reverse теперь являются «ключевыми» (keyword-only).
• Функцию cmp() следует считать устаревшей, а специальный метод __cmp__() больше не поддерживается. Используйте __lt__() для сортировки, __eq__() с __hash__() и другие операции сравнения по необходимости. (Если вам действительно нужна функциональность cmp(), можно использовать выражение (a > b) - (a < b) как эквивалент cmp(a, b).)

Целые числа¶Integers

• PEP 0237: По сути, long переименован в int. То есть существует только один встроенный целочисленный тип с именем int; но он ведёт себя в основном как старый тип long.
• PEP 0238: Выражение вроде 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) байты, но при не-ASCII значениях возникало UnicodeDecodeError. Такое поведение, зависящее от значения, много лет вызывало печальные лица.
• В результате этого изменения подхода почти весь код, использующий 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 символов, тогда как в Python 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.

Новый синтаксис¶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 0274 оправдан. :-)

• Литералы множеств, например {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.)

• List comprehensions no longer support the syntactic form [... for var in item1, item2, ...]. Use [... for var in (item1, item2, ...)] instead. Also note that list comprehensions have different semantics: they are closer to syntactic sugar for a generator expression inside a list() constructor, and in particular the loop control variables are no longer leaked into the surrounding scope.

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

Удалённый синтаксис¶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 0328)
• Классические классы удалены.

Операторы и специальные методы¶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.