Содержание страницы
FAQ по дизайну и истории¶Design and History FAQ
Почему в Python для группировки инструкций используются отступы?¶Why does Python use indentation for grouping of statements?
Гвидо ван Россум считает, что использование отступов для группировки чрезвычайно элегантно и значительно повышает читаемость типичной программы на Python. Большинство людей со временем начинают любить эту особенность.
Поскольку нет фигурных скобок, не может быть расхождений между группировкой, воспринимаемой парсером, и человеческим восприятием. Иногда программисты на C сталкиваются с фрагментом кода вроде такого:
if (x <= y)
x++;
y--;
z++;
Выполняется только оператор x++, если условие истинно, но отступы заставляют думать иначе. Даже опытные программисты на C иногда долго смотрят на это, недоумевая, почему y уменьшается даже для x > y.
Из-за отсутствия скобок начала и конца блока Python гораздо менее подвержен конфликтам стилей оформления кода. В C существует множество способов расстановки фигурных скобок. Если вы привыкли читать и писать код в одном стиле, вы будете чувствовать себя по меньшей мере неуютно, читая (или будучи вынужденным писать) код в другом стиле.
Многие стили кодирования размещают открывающие и закрывающие скобки на отдельных строках. Это делает программы значительно длиннее и тратит ценное пространство экрана, затрудняя получение хорошего обзора программы. В идеале функция должна умещаться на одном экране (скажем, 20–30 строк). 20 строк Python могут сделать гораздо больше работы, чем 20 строк C. Это связано не только с отсутствием открывающих/закрывающих скобок – отсутствие объявлений и высокоуровневые типы данных также играют роль – но синтаксис, основанный на отступах, безусловно, помогает.
Почему простые арифметические операции дают странные результаты?¶Why am I getting strange results with simple arithmetic operations?
Смотрите следующий вопрос.
Почему вычисления с плавающей запятой такие неточные?¶Why are floating-point calculations so inaccurate?
Пользователи часто удивляются результатам вроде этого:
>>> 1.2 - 1.0
0.199999999999999996
и думают, что это ошибка в Python. Это не так. Это мало связано с Python и гораздо больше связано с тем, как нижележащая платформа обрабатывает числа с плавающей запятой.
Тип float в CPython использует C-тип double для хранения. Значение объекта float хранится в двоичном формате с плавающей точкой с фиксированной точностью (обычно 53 бита), и Python использует операции C, которые, в свою очередь, полагаются на аппаратную реализацию в процессоре, для выполнения операций с плавающей точкой. Это означает, что в отношении операций с плавающей точкой Python ведет себя как многие популярные языки, включая C и Java.
Многие числа, которые легко записываются в десятичной записи, не могут быть точно выражены в двоичной плавающей арифметике. Например, после:
>>> x = 1.2
сохранённое значение для x является (очень хорошим) приближением к десятичному значению 1.2, но не равно ему в точности. На типичной машине фактическое сохранённое значение:
1.0011001100110011001100110011001100110011001100110011 (binary)
что в точности равно:
1.1999999999999999555910790149937383830547332763671875 (decimal)
Типичная точность в 53 бита обеспечивает числам с плавающей точкой Python 15–16 десятичных знаков точности.
Для более подробного объяснения обратитесь к главе Арифметика с плавающей точкой в учебнике Python.
Почему строки в Python неизменяемы?¶Why are Python strings immutable?
Есть несколько преимуществ.
Первое – производительность: знание того, что строка неизменяема, позволяет выделить для неё память при создании, и требования к хранению фиксированы и неизменны. Это также одна из причин различия между кортежами и списками.
Другое преимущество в том, что строки в Python считаются такими же «элементарными», как числа. Никакие действия не превратят значение 8 во что-то другое, и в Python никакие действия не превратят строку «eight» во что-то другое.
Почему 'self' нужно указывать явно в определениях и вызовах методов?¶Why must ‘self’ be used explicitly in method definitions and calls?
Идея была заимствована из Modula-3. Она оказалась очень полезной по ряду причин.
Во-первых, становится более очевидным, что вы используете метод или атрибут экземпляра, а не локальную переменную. Чтение self.x или self.meth() абсолютно ясно показывает, что используется переменная экземпляра или метод, даже если вы не знаете определение класса наизусть. В C++ вы можете примерно определить это по отсутствию объявления локальной переменной (предполагая, что глобальные переменные редки или легко узнаваемы) – но в Python нет объявлений локальных переменных, поэтому нужно искать определение класса, чтобы быть уверенным. Некоторые стандарты кодирования C++ и Java требуют, чтобы атрибуты экземпляра имели префикс m_, так что эта явность полезна и в этих языках.
Во-вторых, это означает, что не требуется специального синтаксиса, если вы хотите явно сослаться или вызвать метод из определённого класса. В C++, если вы хотите использовать метод из базового класса, который переопределён в производном классе, нужно использовать оператор :: – в Python вы можете написать baseclass.methodname(self, <argument list>). Это особенно полезно для методов __init__() и в целом в случаях, когда метод производного класса хочет расширить метод базового класса с тем же именем и поэтому должен каким-то образом вызвать метод базового класса.
Наконец, для переменных экземпляра это решает синтаксическую проблему с присваиванием: поскольку локальные переменные в Python – это (по определению!) те переменные, которым присваивается значение в теле функции (и которые не объявлены явно глобальными), должен быть способ сообщить интерпретатору, что присваивание предназначено для переменной экземпляра, а не для локальной переменной, и желательно, чтобы это было синтаксически (из соображений эффективности). C++ делает это через объявления, но в Python нет объявлений, и было бы жаль вводить их только для этой цели. Использование явного self.var отлично решает эту проблему. Аналогично, при использовании переменных экземпляра необходимость писать self.var означает, что ссылки на неквалифицированные имена внутри метода не должны искать в директориях экземпляра. Другими словами, локальные переменные и переменные экземпляра находятся в двух разных пространствах имён, и нужно указать Python, какое пространство имён использовать.
Почему нельзя использовать присваивание в выражении?¶Why can’t I use an assignment in an expression?
Многие, привыкшие к C или Perl, жалуются, что хотят использовать эту идиому C:
while (line = readline(f)) {
// сделать что-то со строкой
}
тогда как в Python приходится писать так:
while True:
line = f.readline()
if not line:
break
... # сделать что-то со строкой
Причина, по которой в выражениях Python не допускается присваивание, – распространённая, трудновыявляемая ошибка в других языках, возникающая из-за такой конструкции:
if (x = 0) {
// обработка ошибок
}
else {
// код, который работает только для ненулевого x
}
Ошибка – простая опечатка: было написано x = 0, что присваивает переменной x значение 0, в то время как предполагалось сравнение x == 0.
Предлагалось множество альтернатив. Большинство из них – это хаки, которые экономят немного набора, но используют произвольный или непонятный синтаксис или ключевые слова и не проходят простой критерий для предложений по изменению языка: конструкция должна интуитивно подсказывать правильный смысл читателю, который с ней ещё не знаком.
Интересное явление: большинство опытных программистов Python узнают идиому while True и, похоже, не сильно скучают по конструкции присваивания в выражении; только новички выражают сильное желание добавить это в язык.
Существует альтернативный способ записи этого, который кажется привлекательным, но в целом менее надёжный, чем решение с “while True”:
line = f.readline()
while line:
... # сделать что-то со строкой...
line = f.readline()
Проблема в том, что если вы передумаете относительно того, как именно вы получаете следующую строку (например, захотите изменить её на sys.stdin.readline()), вам придётся не забыть изменить два места в программе – второе вхождение скрыто внизу цикла.
Лучший подход – использовать итераторы, что позволяет выполнять цикл по объектам с помощью оператора for. Например, файловые объекты поддерживают протокол итератора, поэтому можно просто написать:
for line in f:
... # сделать что-то со строкой...
Почему для одних возможностей Python использует методы (например, list.index()), а для других – функции (например, len(list))?¶Why does Python use methods for some functionality (e.g. list.index()) but functions for other (e.g. len(list))?
Главная причина – история. Функции использовались для тех операций, которые были общими для группы типов и которые должны были работать даже для объектов, не имеющих методов (например, кортежи). Также удобно иметь функцию, которую можно легко применить к аморфной коллекции объектов при использовании функциональных возможностей Python (map(), zip() и другие).
На самом деле, реализация len(), max(), min() как встроенных функций требует меньше кода, чем их реализация в качестве методов для каждого типа. Можно спорить об отдельных случаях, но это часть Python, и сейчас уже слишком поздно вносить такие фундаментальные изменения. Функции должны остаться, чтобы избежать массового нарушения работоспособности кода.
Примечание
Для строковых операций Python перешёл от внешних функций (модуль string) к методам. Однако len() по-прежнему является функцией.
Почему join() – это метод строки, а не списка или кортежа?¶Why is join() a string method instead of a list or tuple method?
Строки стали гораздо больше похожи на другие стандартные типы начиная с Python 1.6, когда были добавлены методы, предоставляющие те же возможности, которые всегда были доступны через функции модуля string. Большинство этих новых методов были широко приняты, но один из них, который, по-видимому, вызывает дискомфорт у некоторых программистов, – это:
", ".join(['1', '2', '4', '8', '16'])
который даёт результат:
"1, 2, 4, 8, 16"
Есть два распространённых аргумента против этого использования.
Первый звучит примерно так: «Выглядит действительно уродливо использовать метод строкового литерала (строковой константы)», на что можно ответить: возможно, но строковый литерал – это просто фиксированное значение. Если методы разрешены для имён, связанных со строками, нет логической причины делать их недоступными для литералов.
Второе возражение обычно формулируется так: «Я действительно говорю последовательности объединить свои элементы с помощью строковой константы». К сожалению, это не так. По какой-то причине, похоже, гораздо меньше проблем с тем, чтобы сделать split() методом строки, так как в этом случае легко увидеть, что
"1, 2, 4, 8, 16".split(", ")
– это инструкция строковому литералу вернуть подстроки, разделённые заданным разделителем (или, по умолчанию, произвольными последовательностями пробельных символов).
join() является методом строки, потому что при его использовании вы указываете строке-разделителю перебрать последовательность строк и вставить себя между соседними элементами. Этот метод можно использовать с любым аргументом, который подчиняется правилам для объектов последовательностей, включая любые новые классы, которые вы можете определить самостоятельно. Аналогичные методы существуют для объектов bytes и bytearray.
Насколько быстры исключения?¶How fast are exceptions?
Блок try/except чрезвычайно эффективен, если исключения не выбрасываются. Однако перехват исключения – дорогостоящая операция. В версиях Python до 2.0 было распространено использование такой идиомы:
try:
value = mydict[key]
except KeyError:
mydict[key] = getvalue(key)
value = mydict[key]
Это имело смысл только тогда, когда вы ожидали, что ключ есть в словаре почти всё время. Если это было не так, вы писали так:
if key in mydict:
value = mydict[key]
else:
value = mydict[key] = getvalue(key)
В этом конкретном случае можно также использовать value = dict.setdefault(key, getvalue(key)), но только если вызов getvalue() достаточно дешёвый, так как он вычисляется в любом случае.
Почему в Python нет оператора switch или case?¶Why isn’t there a switch or case statement in Python?
Это можно легко сделать с помощью последовательности if... elif... elif... else. Было несколько предложений синтаксиса switch, но пока нет консенсуса относительно того, нужно ли и как реализовать проверку диапазонов. Смотрите PEP 275 для полных подробностей и текущего статуса.
Для случаев, когда нужно выбрать из очень большого числа возможностей, можно создать словарь, отображающий значения вариантов на вызываемые функции. Например:
def function_1(...):
...
functions = {'a': function_1,
'b': function_2,
'c': self.method_1, ...}
func = functions[value]
func()
Для вызова методов объектов можно ещё больше упростить, используя встроенную функцию getattr() для получения методов с определённым именем:
def visit_a(self, ...):
...
...
def dispatch(self, value):
method_name = 'visit_' + str(value)
method = getattr(self, method_name)
method()
Рекомендуется использовать префикс для имён методов, например visit_ в этом примере. Без такого префикса, если значения поступают из ненадёжного источника, злоумышленник сможет вызвать любой метод вашего объекта.
Нельзя ли эмулировать потоки в интерпретаторе, вместо того чтобы полагаться на OS-зависимую реализацию потоков?¶Can’t you emulate threads in the interpreter instead of relying on an OS-specific thread implementation?
Ответ 1: К сожалению, интерпретатор помещает как минимум один кадр стека C для каждого кадра стека Python. Кроме того, расширения могут вызывать Python в почти случайные моменты. Поэтому полная реализация потоков требует поддержки потоков на уровне C.
Ответ 2: К счастью, существует Stackless Python, который имеет полностью переработанный цикл интерпретатора, избавляющийся от стека C.
Почему лямбда-формы не могут содержать инструкции?¶Why can’t lambda forms contain statements?
Лямбда-формы в Python не могут содержать инструкции, потому что синтаксическая структура Python не позволяет вкладывать инструкции в выражения. Однако в Python это не является серьёзной проблемой. В отличие от лямбда-форм в других языках, которые добавляют функциональность, лямбды в Python – это просто сокращённая запись на случай, если вам лень определять функцию.
Функции в Python уже являются объектами первого класса и могут объявляться в локальной области видимости. Поэтому единственное преимущество использования лямбда-формы вместо локально определённой функции – это то, что не нужно придумывать имя для функции. Но имя – это просто локальная переменная, которой присваивается объект функции (точно тот же тип объекта, который возвращает лямбда-форма)!
Можно ли скомпилировать Python в машинный код, C или другой язык?¶Can Python be compiled to machine code, C or some other language?
Практический ответ:
Cython и Pyrex компилируют модифицированную версию Python с необязательными аннотациями в C-расширения. Weave позволяет легко смешивать код Python и C различными способами для повышения производительности. Nuitka – перспективный компилятор Python в C++, стремящийся поддерживать весь язык Python.
Теоретический ответ:
Не так просто. Высокоуровневые типы данных Python, динамическая типизация объектов и вызов интерпретатора во время выполнения (с помощью eval() или exec()) вместе означают, что наивно «скомпилированная» программа на Python, вероятно, будет состоять в основном из вызовов в систему выполнения Python, даже для, казалось бы, простых операций, таких как x+1.
Несколько проектов, описанных в новостной группе Python или на прошлых конференциях по Python, показали, что такой подход возможен, хотя достигнутое ускорение пока скромное (например, 2 раза). Jython использует ту же стратегию для компиляции в байт-код Java. (Джим Хугунин продемонстрировал, что в сочетании с анализом всей программы для небольших демонстрационных примеров возможно ускорение в 1000 раз. Подробнее см. в материалах конференции по Python 1997 года.)
Как Python управляет памятью?¶How does Python manage memory?
Детали управления памятью в Python зависят от реализации. Стандартная реализация Python, CPython, использует подсчёт ссылок для обнаружения недоступных объектов и другой механизм для сбора циклических ссылок, периодически выполняя алгоритм обнаружения циклов, который ищет недоступные циклы и удаляет участвующие объекты. Модуль gc предоставляет функции для выполнения сборки мусора, получения отладочной статистики и настройки параметров сборщика.
Однако другие реализации (такие как Jython или PyPy) могут полагаться на другой механизм, например, полноценный сборщик мусора. Это различие может вызвать некоторые тонкие проблемы переносимости, если код на Python зависит от поведения реализации с подсчётом ссылок.
В некоторых реализациях Python следующий код (который нормально работает в CPython) вероятно исчерпает файловые дескрипторы:
for file in very_long_list_of_files:
f = open(file)
c = f.read(1)
Действительно, используя механизм подсчёта ссылок и деструкторов CPython, каждое новое присваивание f закрывает предыдущий файл. Однако в традиционной сборке мусора эти файловые объекты будут собраны (и закрыты) через различные и, возможно, длительные промежутки времени.
Если вы хотите писать код, который будет работать с любой реализацией Python, следует явно закрывать файл или использовать оператор with; это будет работать независимо от схемы управления памятью:
for file in very_long_list_of_files:
with open(file) as f:
c = f.read(1)
Почему CPython не использует более традиционную схему сборки мусора?¶Why doesn’t CPython use a more traditional garbage collection scheme?
Во-первых, это не является стандартной возможностью C, и поэтому она не переносима. (Да, мы знаем о библиотеке Boehm GC. Она содержит фрагменты ассемблерного кода для большинства распространённых платформ, но не для всех, и хотя она в основном прозрачна, она не полностью прозрачна; требуются патчи, чтобы Python работал с ней.)
Традиционная сборка мусора также становится проблемой, когда Python встраивается в другие приложения. В то время как в автономном Python можно заменить стандартные malloc() и free() на версии, предоставляемые библиотекой сборки мусора, приложение, встраивающее Python, может захотеть иметь свою собственную замену для malloc() и free() и не хотеть использовать версию Python. Сейчас CPython работает с любой реализацией, которая правильно реализует malloc() и free().
Почему при завершении CPython не освобождается вся память?¶Why isn’t all memory freed when CPython exits?
Объекты, на которые есть ссылки из глобальных пространств имён модулей Python, не всегда освобождаются при завершении Python. Это может происходить при наличии циклических ссылок. Также существуют определённые фрагменты памяти, выделяемые библиотекой C, которые невозможно освободить (например, инструмент вроде Purify будет жаловаться на них). Однако Python активно очищает память при завершении и старается уничтожить каждый объект.
Если вы хотите принудительно заставить Python удалять определённые объекты при освобождении памяти, используйте модуль atexit для запуска функции, которая выполнит эти удаления.
Почему существуют отдельные типы данных – кортеж и список?¶Why are there separate tuple and list data types?
Списки и кортежи, хотя и похожи во многих отношениях, обычно используются принципиально по-разному. Кортежи можно рассматривать как аналоги записей Pascal или структур C; это небольшие коллекции связанных данных, которые могут быть разных типов и обрабатываются как группа. Например, декартова координата уместно представляется в виде кортежа из двух или трёх чисел.
Списки, с другой стороны, больше похожи на массивы в других языках. Они обычно содержат переменное количество объектов одного типа, с которыми работают по одному. Например, os.listdir('.') возвращает список строк, представляющих файлы в текущем каталоге. Функции, работающие с этим выводом, обычно не сломаются, если вы добавите в каталог ещё один-два файла.
Кортежи неизменяемы, то есть после создания кортежа нельзя заменить какой-либо его элемент новым значением. Списки изменяемы, то есть элементы списка всегда можно изменить. Только неизменяемые элементы можно использовать в качестве ключей словаря, поэтому в качестве ключей можно использовать только кортежи, но не списки.
Как реализованы списки?¶How are lists implemented?
Списки Python – это на самом деле массивы переменной длины, а не связные списки в стиле Lisp. Реализация использует непрерывный массив ссылок на другие объекты и хранит указатель на этот массив и его длину в структуре заголовка списка.
Это делает индексацию списка a[i] операцией, стоимость которой не зависит ни от размера списка, ни от значения индекса.
При добавлении или вставке элементов массив ссылок изменяет размер. Применяется некоторая хитрость для повышения производительности при многократном добавлении: когда массив нужно увеличить, выделяется дополнительное пространство, чтобы следующие несколько раз не требовалось реально изменять размер.
Как реализованы словари?¶How are dictionaries implemented?
Словари Python реализованы как изменяемые хеш-таблицы. По сравнению с B-деревьями это обеспечивает лучшую производительность поиска (самой частой операции) в большинстве случаев, а реализация проще.
Словари работают путём вычисления хеш-кода для каждого ключа, хранящегося в словаре, с помощью встроенной функции hash(). Хеш-код сильно варьируется в зависимости от ключа; например, «Python» даёт хеш -539294296, а «python» (строка, отличающаяся на один бит) даёт 1142331976. Затем хеш-код используется для вычисления позиции во внутреннем массиве, где будет храниться значение. Если предположить, что все ключи имеют разные хеш-значения, это означает, что словари выполняют поиск ключа за постоянное время – O(1) в обозначениях компьютерных наук. Это также означает, что порядок ключей не сохраняется, и обход массива с помощью .keys() и .items() выдаёт содержимое словаря в произвольном, перемешанном порядке.
Почему ключи словаря должны быть неизменяемыми?¶Why must dictionary keys be immutable?
Реализация словарей на основе хэш-таблиц использует хэш-значение, вычисленное из значения ключа, для поиска ключа. Если бы ключ был изменяемым объектом, его значение могло бы измениться, и, следовательно, его хэш также мог бы измениться. Но поскольку тот, кто изменяет объект-ключ, не может знать, что он используется в качестве ключа словаря, он не может переместить запись в словаре. Тогда при попытке найти тот же объект в словаре он не будет найден, потому что его хэш-значение стало другим. Если попытаться найти старое значение, оно тоже не будет найдено, поскольку значение объекта, находящегося в той хэш-корзине, будет другим.
Если вам нужен словарь, индексируемый списком, просто преобразуйте список в кортеж; функция tuple(L) создаёт кортеж с теми же элементами, что и список L. Кортежи неизменяемы и поэтому могут использоваться в качестве ключей словаря.
Некоторые неприемлемые решения, которые предлагались:
Хэшировать списки по их адресу (идентификатору объекта). Это не работает, потому что если создать новый список с тем же значением, он не будет найден; например:
mydict = {[1, 2]: '12'} print(mydict[[1, 2]])
вызовет исключение KeyError, потому что идентификатор [1, 2], используемый во второй строке, отличается от идентификатора в первой строке. Другими словами, ключи словаря следует сравнивать с помощью ==, а не с помощью is.
Создавать копию при использовании списка в качестве ключа. Это не работает, потому что список, будучи изменяемым объектом, может содержать ссылку на самого себя, и тогда код копирования попадёт в бесконечный цикл.
Разрешить списки в качестве ключей, но предупредить пользователя не изменять их. Это позволило бы появлению класса трудно отслеживаемых ошибок в программах, когда вы забыли или случайно изменили список. Это также нарушает важное свойство словарей: каждое значение в d.keys() может использоваться как ключ словаря.
Помечайте списки как доступные только для чтения, как только они используются в качестве ключа словаря. Проблема в том, что изменить значение может не только объект верхнего уровня: можно использовать кортеж, содержащий список, в качестве ключа. Добавление чего-либо в качестве ключа в словарь потребует пометить все достижимые оттуда объекты как доступные только для чтения – и снова самореферентные объекты могут вызвать бесконечный цикл.
Существует трюк, позволяющий обойти это, если необходимо, но используйте его на свой страх и риск: Можно обернуть изменяемую структуру в экземпляр класса, у которого есть и метод __eq__(), и метод __hash__(). Затем нужно убедиться, что хеш-значение для всех таких объектов-обёрток, находящихся в словаре (или другой структуре на основе хеша), остаётся неизменным, пока объект находится в словаре (или другой структуре).
class ListWrapper:
def __init__(self, the_list):
self.the_list = the_list
def __eq__(self, other):
return self.the_list == other.the_list
def __hash__(self):
l = self.the_list
result = 98767 - len(l)*555
for i, el in enumerate(l):
try:
result = result + (hash(el) % 9999999) * 1001 + i
except Exception:
result = (result % 7777777) + i * 333
return result
Обратите внимание, что вычисление хеша усложняется тем, что некоторые элементы списка могут быть нехешируемыми, а также возможностью арифметического переполнения.
Кроме того, всегда должно выполняться условие: если o1 == o2 (т.е. o1.__eq__(o2) is True), то hash(o1) == hash(o2) (т.е. o1.__hash__() == o2.__hash__()), независимо от того, находится объект в словаре или нет. Если не соблюдать эти ограничения, словари и другие структуры на основе хеша будут работать некорректно.
В случае ListWrapper, когда объект-обёртка находится в словаре, обёрнутый список не должен изменяться, чтобы избежать аномалий. Не делайте этого, если вы не готовы тщательно обдумать требования и последствия их неправильного выполнения. Считайте себя предупреждёнными.
Почему list.sort() не возвращает отсортированный список?¶Why doesn’t list.sort() return the sorted list?
В ситуациях, когда производительность важна, создание копии списка только для его сортировки было бы расточительством. Поэтому list.sort() сортирует список на месте. Чтобы напомнить вам об этом, он не возвращает отсортированный список. Так вы случайно не перезапишете список, когда вам нужна отсортированная копия, но при этом нужно сохранить и исходный.
Если нужно вернуть новый список, используйте вместо этого встроенную функцию sorted(). Эта функция создаёт новый список из переданного итерируемого объекта, сортирует его и возвращает. Например, вот как перебрать ключи словаря в отсортированном порядке:
for key in sorted(mydict):
... # делайте что угодно с mydict[key]...
Как указать и обеспечить соблюдение спецификации интерфейса в Python?¶How do you specify and enforce an interface spec in Python?
Спецификация интерфейса модуля, предоставляемая такими языками, как C++ и Java, описывает прототипы методов и функций модуля. Многие считают, что проверка соблюдения спецификаций интерфейса на этапе компиляции помогает при построении больших программ.
В Python 2.6 добавлен модуль abc, который позволяет определять абстрактные базовые классы (ABC). Затем можно использовать isinstance() и issubclass() для проверки того, реализует ли экземпляр или класс определённый ABC. Модуль collections определяет набор полезных ABC, таких как Iterable, Container и MutableMapping.
В Python многие преимущества спецификаций интерфейсов достигаются за счёт правильной дисциплины тестирования компонентов. Также есть инструмент PyChecker, который помогает находить проблемы, вызванные наследованием.
Хороший набор тестов для модуля может одновременно служить регрессионным тестом, спецификацией интерфейса модуля и набором примеров. Многие модули Python можно запускать как скрипт для выполнения простого «самотестирования». Даже модули, использующие сложные внешние интерфейсы, часто можно тестировать изолированно, применяя тривиальные «заглушки», эмулирующие внешний интерфейс. Модули doctest и unittest или сторонние тестовые фреймворки можно использовать для построения исчерпывающих наборов тестов, проверяющих каждую строку кода в модуле.
Правильная дисциплина тестирования может помочь в создании больших сложных приложений на Python не хуже, чем спецификации интерфейсов. На самом деле она может быть даже лучше, поскольку спецификация интерфейса не может проверить некоторые свойства программы. Например, метод append() ожидается, что он добавляет новые элементы в конец некоторого внутреннего списка; спецификация интерфейса не может проверить, что ваша реализация append() действительно делает это правильно, но в наборе тестов проверить это свойство тривиально.
Написание тестовых наборов очень полезно, и, возможно, стоит проектировать код с расчётом на лёгкое тестирование. Одна из набирающих популярность методик, разработка через тестирование (test-directed development), требует сначала написать части тестового набора, а затем уже писать сам код. Конечно, Python позволяет быть небрежным и вообще не писать тесты.
Почему нет goto?¶Why is there no goto?
Исключения можно использовать для создания «структурированного goto», которое работает даже между вызовами функций. Многие считают, что исключения могут удобно эмулировать все разумные применения конструкций «go» или «goto» из C, Fortran и других языков. Например:
class label(Exception): pass # объявить метку
try:
...
if condition: raise label() # перейти к метке
...
except label: # куда перейти
pass
...
Это не позволяет перепрыгнуть в середину цикла, но это обычно считается злоупотреблением goto в любом случае. Используйте с осторожностью.
Почему сырые строки (r-strings) не могут заканчиваться обратной косой чертой?¶Why can’t raw strings (r-strings) end with a backslash?
Более точно, они не могут заканчиваться нечётным количеством обратных слешей: непарный обратный слеш в конце экранирует закрывающий символ кавычки, оставляя строку незавершённой.
Сырые строки были разработаны для упрощения создания входных данных для обработчиков (в основном, движков регулярных выражений), которые хотят выполнять свою собственную обработку экранирования обратным слешем. Такие обработчики в любом случае считают непарный завершающий обратный слеш ошибкой, поэтому сырые строки это запрещают. Взамен они позволяют передать символ кавычки, экранируя его обратным слешем. Эти правила хорошо работают, когда r-строки используются по назначению.
Если вы пытаетесь построить пути Windows, учтите, что все системные вызовы Windows принимают и прямые слеши:
f = open("/mydir/file.txt") # работает отлично!
Если вы пытаетесь построить путь для команды DOS, попробуйте, например, один из
dir = r"\this\is\my\dos\dir" "\\"
dir = r"\this\is\my\dos\dir\ "[:-1]
dir = "\\this\\is\\my\\dos\\dir\\"
Почему в Python нет оператора “with” для присваивания атрибутов?¶Why doesn’t Python have a “with” statement for attribute assignments?
В Python есть инструкция ‘with’, которая оборачивает выполнение блока, вызывая код при входе в блок и при выходе из него. В некоторых языках есть конструкция, которая выглядит так:
with obj:
a = 1 # эквивалентно obj.a = 1
total = total + 1 # obj.total = obj.total + 1
В Python такая конструкция была бы неоднозначной.
Другие языки, такие как Object Pascal, Delphi и C++, используют статическую типизацию, поэтому можно однозначно узнать, какому члену выполняется присваивание. В этом и заключается основная суть статической типизации – компилятор всегда знает область видимости каждой переменной на этапе компиляции.
Python использует динамическую типизацию. Невозможно заранее узнать, какой атрибут будет использован во время выполнения. Атрибуты-члены могут добавляться или удаляться из объектов на лету. Из-за этого невозможно при простом чтении понять, на какой атрибут идёт ссылка: локальный, глобальный или атрибут-член?
Например, рассмотрим следующий неполный фрагмент кода:
def foo(a):
with a:
print(x)
Фрагмент предполагает, что «a» должно иметь атрибут с именем «x». Однако в Python нет ничего, что говорило бы об этом интерпретатору. Что должно произойти, если «a» является, скажем, целым числом? Если существует глобальная переменная с именем «x», будет ли она использоваться внутри блока with? Как видите, динамическая природа Python делает такой выбор гораздо более сложным.
Однако основное преимущество «with» и подобных языковых возможностей (сокращение объёма кода) легко достигается в Python с помощью присваивания. Вместо:
function(args).mydict[index][index].a = 21
function(args).mydict[index][index].b = 42
function(args).mydict[index][index].c = 63
напишите это:
ref = function(args).mydict[index][index]
ref.a = 21
ref.b = 42
ref.c = 63
Это также даёт побочный эффект ускорения выполнения, так как привязки имён в Python разрешаются во время выполнения, и второй вариант требует разрешения только один раз.
Почему двоеточия обязательны для операторов if/while/def/class?¶Why are colons required for the if/while/def/class statements?
Двоеточие требуется в первую очередь для улучшения читаемости (один из результатов экспериментального языка ABC). Рассмотрим это:
if a == b
print(a)
против
if a == b:
print(a)
Обратите внимание, что второй вариант читается немного легче. Также обратите внимание, как двоеточие выделяет пример в этом ответе из FAQ; это стандартное использование в английском языке.
Ещё одна второстепенная причина заключается в том, что двоеточие упрощает работу редакторов с подсветкой синтаксиса; они могут искать двоеточия, чтобы решить, когда нужно увеличить отступ, вместо более тщательного разбора текста программы.
Почему Python разрешает запятые в конце списков и кортежей?¶Why does Python allow commas at the end of lists and tuples?
Python позволяет добавлять завершающую запятую в конце списков, кортежей и словарей:
[1, 2, 3,]
('a', 'b', 'c',)
d = {
"A": [1, 5],
"B": [6, 7], # последняя завершающая запятая необязательна, но считается хорошим стилем
}
Для этого есть несколько причин.
Когда литерал списка, кортежа или словаря разбит на несколько строк, добавлять новые элементы проще, потому что не нужно помнить о добавлении запятой в предыдущей строке. Строки также можно сортировать в редакторе, не создавая синтаксической ошибки.
Случайный пропуск запятой может привести к ошибкам, которые трудно диагностировать. Например:
x = [
"fee",
"fie"
"foo",
"fum"
]
Этот список выглядит так, будто в нём четыре элемента, но на самом деле их три: «fee», «fiefoo» и «fum». Всегда добавляя запятую, можно избежать этого источника ошибок.
Разрешение завершающей запятой также может упростить программную генерацию кода.