Автостопом по Python

Питонисты (ветераны разработки на Python) рады тому, что их язык настолько понятен, — люди, которые никогда не занимались разработкой, способны разобраться в работе программы при чтении ее исходного кода. Легкость чтения лежит в основе дизайна Python (важно понимать, что написанный код будет прочитан много раз).

Одна из причин, почему код Python прост для понимания, заключается в информативном руководстве по стилю написания кода (оно представлено в двух Предложениях по развитию Python (Python Enhancement Proposal) PEP 20 и PEP 8; о них скажем пару слов) и питонских идиомах. Если питонист указывает на фрагмент кода и говорит, что он не питонский, это обычно означает, что строки не соответствуют распространенным принципам и не являются читаемыми. Конечно, «глупая последовательность — пугало маленьких умов»[36]. Педантичное следование PEP может снизить читаемость и понятность.

PEP 8

PEP 8 де-факто представляет собой руководство по стилю написания кода Python. В нем рассматриваются соглашения по именованию, структура кода, пустые области (табуляция против пробелов) и другие аналогичные темы.

Мы рекомендуем изучить его. Все сообщество Python старается следовать принципам, изложенным в этом документе. Некоторые проекты время от времени могут отступать от него, а другие (вроде Requests — http://bit.ly/reitz-code-style) — добавлять поправки к рекомендациям.

Писать код с учетом принципов PEP 8 — хорошая идея (помогает разработчикам создавать более стабильный код). С помощью программы pep8 (https://github.com/jcrocholl/pep8), которая запускается из командной строки, можно проверить код на соответствие принципам PEP 8. Для установки этой программы введите в терминале такую команду:

$ pip3 install pep8

Рассмотрим пример того, что вы можете увидеть при запуске команды pep8:

$ pep8 optparse.py

optparse.py:69:11: E401 multiple imports on one line

optparse.py:77:1: E302 expected 2 blank lines, found 1

optparse.py:88:5: E301 expected 1 blank line, found 0

optparse.py:222:34: W602 deprecated form of raising exception

optparse.py:347:31: E211 whitespace before '('

optparse.py:357:17: E201 whitespace after '{'

optparse.py:472:29: E221 multiple spaces before operator

optparse.py:544:21: W601.has_key() is deprecated, use 'in'

Большинство недостатков можно легко исправить, рекомендации по их устранению даются в PEP 8. В руководстве по стилю написания кода для Requests приведены примеры хорошего и плохого кода (лишь немного отличаются от оригинального PEP 8).

Инструменты контроля качества кода, о которых мы говорили в разделе «Текстовые редакторы» в главе 3, обычно используют программу pep8, поэтому вы также можете установить один из них для проверки кода внутри редактора или IDE. Или же можете выбрать команду auto pep8, которая автоматически переформатирует код согласно PEP 8. Установить ее можно так:

$ pip3 install autopep8

Чтобы переформатировать файл (перезаписав оригинал), введите следующую команду:

$ autopep8 — in-place optparse.py

Если вы не добавите флаг — in-place, это заставит программу вывести модифицированный код в консоль (или записать в другой файл). Флаг — aggressive выполнит более существенные изменения, его можно применить несколько раз для получения значительного эффекта.

PEP 20 (также известный как «Дзен Питона»)

PEP 20 (https://www.python.org/dev/peps/pep-0020/) (набор принципов для принятия решений в Python) всегда доступен по команде import this в оболочке Python. Несмотря на название, PEP 20 содержит 19 афоризмов, а не 20 (последний не был записан).

Реальная история «Дзена Питона» увековечена в статье Барри Уорсоу (Barry Warsaw) Import this and the Zen of Python (http://bit.ly/import-this-zen-python).

Для того чтобы увидеть пример использования каждого из этих афоризмов, обратитесь к презентации Хантера Блэнкса (Hunter Blanks) PEP 20 (The Zen of Python) by Example (http://artifex.org/~hblanks/talks/2011/pep20_by_example.pdf). Рэймонд Хеттингер (Raymond Hettinger) также демонстрирует применение этих принципов в своей речи Beyond PEP 8: Best Practices for Beautiful, Intelligible Code (http://bit.ly/beyond-pep-8).

Общие советы

В этом разделе приводятся концепции, связанные со стилем (надеемся, вы с ними согласитесь). Зачастую они применимы и к другим языкам. Некоторые следуют непосредственно из «Дзена Питона», другие основаны на здравом смысле. Они подтверждают наш принцип работы: при написании кода Python выбирать наиболее очевидный способ его представления из имеющихся вариантов.

В Python предпочтителен наиболее явный способ выражения:

def make_dict(*args):

def make_dict(x, y):

····x, y = args

····return {'x': x, 'y': y}

····return dict(**locals())

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

В каждой строке размещайте только одно выражение. Использование сложных выражений (вроде абстракция списков (иначе называют списковыми включениями — list comprehensions)) позволяется и даже поощряется за их краткость и выразительность, но признаком хорошего тона будет размещение отдельных выражений на разных строках. Это поможет создавать более простые для понимания разности[37], когда подобное выражение изменяется:

print('one'); print('two')

print('one')

print('two')

if x == 1: print('one')

if x == 1:

····print('one')

if ( and

cond1 = 

····):

cond2 = 

····# сделать что-нибудь

if cond1 and cond2:

····# сделать что-нибудь

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

Обработка ошибок в Python выполняется с помощью выражения try. Пример из пакета HowDoI (более подробно описывается в разделе «HowDoI» в главе 5) Бена Глейтсмана (Ben Gleitzman) показывает, когда замалчивать ошибки приемлемо:

def format_output(code, args):

····if not args['color']:

········return code

····lexer = None

····# попробуем отыскать лексеры с помощью тегов Stack Overflow

····# или аргументов query

····for keyword in args['query'].split() + args['tags']:

········try:

············lexer = get_lexer_by_name(keyword)

············break

········except ClassNotFound:

············pass

····# лексер не найден, пробуем угадать

····if not lexer:

········lexer = guess_lexer(code)

····return highlight(code,

····················lexer,

····················TerminalFormatter(bg='dark'))

Перед вами часть пакета, который предоставляет сценарий командной строки, позволяющий найти в Интернете (по умолчанию на сайте Stack Overflow) способ выполнить задачу по программированию. Функция format_output() подсвечивает синтаксис, просматривая теги вопроса на предмет строки, которую смог разобрать лексер (также он называется токенайзером; теги python, java или bash позволят определить лексер, который нужно использовать для разбиения и подсвечивания кода), а затем, если он даст сбой, пробует определить язык по самому коду. Когда программа достигает оператора try, она может пойти по одному из трех путей:

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

• лексер не найден, генерируется и обрабатывается исключение ClassNotFound — и ничего не происходит. Цикл продолжит выполнение до тех пор, пока не завершится самостоятельно или не будет найден лексер;

• генерируется какое-то другое исключение (например, KeyboardInterrupt), которое не обрабатывается и поднимается на верхний уровень, останавливая выполнение.

Часть афоризма «не замалчиваются» препятствует чрезмерному выявлению ошибок. Рассмотрим пример (можете попробовать запустить его в отдельном окне консоли — так будет проще прервать выполнение, когда вы во все вникнете):

>>> while True:

… ····try:

… ········print("nyah", end=" ")

… ····except:

… ········pass

Или не пробуйте запускать его. Поскольку для блока except не указано конкретное исключение, он будет отлавливать все исключения, в том числе KeyboardInterrupt (Ctrl+C в консоли POSIX), и игнорировать их. Соответственно, он проигнорирует множество ваших попыток прервать его работу. Это не просто проблема с прерываниями — блок except также может скрывать ошибки, что вызовет проблемы в будущем (их станет трудно диагностировать). Поэтому не замалчивайте ошибки: всегда явно указывайте имена исключений, которые хотите поймать, и обрабатывайте только их. Если вы хотите просто записать в журнал или как-то еще убедиться в наличии исключения и вызвать его повторно, как в следующем сниппете, тогда все в порядке. Только не замалчивайте ошибки (не обрабатывая их и не вызывая повторно):

>>> while True:

… ····try:

… ········print("ni", end="-")

… ····except:

… ········print("An exception happened. Raising.")

… ········raise

Ваш выбор при дизайне API определит последующую возможность взаимодействовать с функцией. Аргументы можно передавать в функции четырьмя разными способами.

Позиционные аргументы обязательны и не имеют значений по умолчанию.

Аргументы с ключевым словом необязательны и имеют значения по умолчанию.

Список с произвольным количеством аргументов необязателен и не имеет значений по умолчанию.

Словарь с произвольным количеством аргументов с ключевым словом необязателен и не имеет значений по умолчанию.

Рассмотрим, когда можно использовать каждый метод передачи аргументов.

• Позиционные аргументы. Применяйте этот метод, когда у вас всего несколько аргументов для функции, которые являются частью ее значения и имеют правильный порядок. Например, пользователь без труда вспомнит, что у функций send(message, recipient) или point(x, y) должны быть два аргумента, а также порядок этих аргументов.

Антишаблон: при вызове функций можно поменять местами имена аргументов, например так: send(recipient="World", message="The answer is 42.") и point(y=2, x=1). Это снижает читаемость. Используйте более понятные вызовы send("The answer is 42", "World") и point(1, 2).

• Аргументы с ключевым словом. Когда функция имеет более двух или трех позиционных параметров, ее сигнатуру сложнее запомнить. В этом случае можно применить аргументы с ключевым словом, которые имеют значения по умолчанию. Например, более полная версия функции send может иметь сигнатуру send(message, to, cc=None, bcc=None). Здесь параметры cc и bcc являются необязательными и равны None, если для них не получено значение.

Антишаблон: можно отправить аргументы в правильном порядке, но не указывать их имена явно, например send("42", "Frankie", "Benjy", "Trillian"), переслав скрытую копию пользователю с именем Триллиан. Можно также передать именованные аргументы в неправильном порядке, например send("42", "Frankie", bcc="Trillian", cc="Benjy"). Если у вас нет веской причины делать это, лучше всего использовать вариант, приближенный к определению функции: send("42", "Frankie", cc="Benjy", bcc="Trillian").

• Список с произвольным количеством аргументов. Такой список определяется с помощью конструкции *args, которая указывает на произвольное количество позиционных аргументов. В теле функции args будет играть роль кортежа, состоящего из всех оставшихся позиционных аргументов. Например, функция send(message, *args) также может быть вызвана, когда каждый получатель будет представлен отдельным аргументом: send("42", "Frankie", "Benjy", "Trillian"). В теле функции конструкция args будет равна выражению ("Frankie", "Benjy", "Trillian"). Хороший пример, иллюстрирующий этот подход, — функция print.

Подводный камень: если функция получает список аргументов одного вида, более понятным будет использование списка или любой другой последовательности. Если функция send в этом примере принимает несколько получателей, мы определим ее явно как send(message, recipients) и будем вызывать как send("42", ["Benjy", "Frankie", "Trillian"]).

• Словарь с произвольным количеством аргументов с ключевым словом. Такой словарь определяется с помощью конструкции **kwargs, которая указывает на произвольное количество именованных аргументов. В теле функции kwargs будет словарем, содержащим все переданные именованные аргументы, которые не были «пойманы» другими аргументами с ключевым словом в сигнатуре функции. Это может быть полезно при журналировании. Средства форматирования на разных уровнях могут принять необходимую им информацию, минуя пользователя.

Подводный камень: эти мощные приемы нужно применять только в том случае, когда это действительно необходимо. Если же имеется более простая и прозрачная конструкция, то для выражения предназначения функции следует выбрать именно ее.

Какие аргументы станут позиционными, а какие — необязательными, зависит только от программиста, который пишет функцию. От него также зависит наличие передачи произвольного количества аргументов. В конце концов, должен существовать один (предпочтительно всего один) очевидный способ это сделать. Другие пользователи оценят ваши усилия, если функции, написанные на Python:

• легко прочитать (имя и аргументы не требуют объяснения);

• легко изменить (добавление нового аргумента с ключевым словом не разрушит другие части кода).

Python поставляется с богатым набором инструментов (за что его любят хакеры), который позволяет вам делать абсолютно невероятные вещи, например:

• изменять способ создания объектов;

• изменять способ импортирования модулей Python;

• встраивать в Python подпрограммы, написанные на С.

Все эти действия имеют недостатки, поэтому всегда лучше выбирать прямолинейный способ достижения цели. Основной минус: при использовании подобных конструкций снижается читаемость, поэтому то, что вы получаете в результате, должно быть более важным, чем потеря читаемости. Многие инструменты, предназначенные для анализа кода, не смогут работать с таким «волшебным» кодом.

Разработчик Python должен знать о таких практически бесконечных возможностях, поскольку это вселяет уверенность в том, что нерешаемых проблем не существует. Однако важно знать, как и когда применять эти знания нельзя.

Как и мастера кун-фу, питонисты знают, как можно убить одним пальцем, и никогда этого не делают.

Как уже демонстрировалось, с помощью Python можно делать многое, но некоторые приемы потенциально могут быть опасными. В частности, любой клиентский код может переопределить свойства и методы объекта: в Python нет ключевого слова private. Эта философия сильно отличается от той, что присуща высокозащищенным языкам вроде Java, — они имеют множество механизмов, предотвращающих неверное использование. Философия Python сосредоточена во фразе «Мы все — ответственные пользователи».

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

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

Использование этой концепции всеми одобряется: имя любого метода или свойства, к которым клиентский код не должен получить доступ, должно начинаться с нижнего подчеркивания. Это гарантирует более качественное разделение обязанностей и упрощает внесение изменений в код. Всегда можно сделать закрытое свойство открытым, обратное же действие выполнить гораздо сложнее.

Когда сложность функции увеличивается, зачастую вы можете встретить несколько выражений return в теле этой функции. Однако для того, чтобы ее было проще понять и прочесть, возвращайте осмысленные значения из минимально возможного количества точек.

Выйти из функции можно в двух случаях: при появлении ошибки или при возвращении значения после того, как функция нормально отработает. Когда функция не может работать корректно, уместно вернуть значение None или False. В этом случае лучше вернуть значение из функции максимально рано после его обнаружения, дабы упростить структуру функции: весь код, который находится после выражения возврата-в-случае-сбоя, будет считать, что все условия соблюдены, и продолжит вычисление основного результата функции. Необходимы несколько подобных выражений return.

Однако везде, где это возможно, имейте только одну точку выхода — сложно выполнять отладку для функций, когда вам сначала нужно определить, какое выражение return ответственно за результат. Наличие единой точки выхода из функции также поможет избавиться от некоторых ветвей кода, поскольку наличие пары точек выхода, возможно, намекает на то, что необходимо провести подобный рефакторинг. Код в следующем примере нельзя назвать плохим, но его можно сделать более чистым (как это показано в комментариях):

def select_ad(third_party_ads, user_preferences):

····if not third_party_ads:

········return None # Лучше сгенерировать исключение

····if not user_preferences:

········return None # Лучше сгенерировать исключение

····# Сложный код, предназначенный для выбора best_ad

····# Из доступных вариантов на основе индивидуальных предпочтений…

····# Постарайтесь устоять перед искушением вернуть best_ad в случае успеха…

····if not best_ad:

········# Запасной план определения best_ad

····return best_ad # Единая точка выхода, которая поможет обслуживать код

Соглашения

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

Если вам не нужно явно сравнивать свое значение со значением True, None или 0, вы можете добавить его к оператору if, как в следующих примерах (см. статью «Проверка значения на правдивость» (http://docs.python.org/library/stdtypes.html#truth-value-testing) — там представлен список значений, которые расцениваются как False).

if attr == True:

# Просто проверяем значение

····print 'True!'

if attr:

····print 'attr is truthy!'

# или проверяем на противоположное значение

if not attr:

····print 'attr is falsey!'

# если вам нужно только значение 'True'

if attr is True:

····print 'attr is True'

if attr == None:

# или явно проверяем на значение None

····print 'attr is None!'

if attr is None:

····print 'attr is None!'

Используйте синтаксис x in d вместо метода dict.has_key или передавайте аргумент по умолчанию в метод dict.get().

>>> d = {'hello': 'world'}

>>> d = {'hello': 'world'}

>>>

>>>

>>> if d.has_key('hello'):

>>> print d.get('hello', 'default_value')

… ····print(d['hello'])

world

# prints 'world'

>>> print d.get('howdy', 'default_value')

… else:

default_value

… ····print('default_value')

>>>

…

>>> # или:

world

… if 'hello' in d:

… ····print(d['hello'])

…

world

Списковые включения — мощный способ работы со списками (для получения более подробной информации обратитесь к соответствующей статье в руководстве The Python Tutorial по адресу http://docs.python.org/tutorial/datastructures.html#list-comprehensions). Функции map() и filter() могут выполнять операции со списками с помощью другого, более выразительного синтаксиса.

# Отфильтруем все элементы,

# Списковое включение выглядит

# чье значение превышает 4

# прозрачнее

a = [3, 4, 5]

a = [3, 4, 5]

b = []

b = [i for i in a if i > 4]

for i in a:

# Или:

····if i > 4:

b = filter(lambda x: x > 4, a)

········b.append(i)

# Добавим 3 к каждому элементу списка

# Здесь также прозрачнее

a = [3, 4, 5]

a = [3, 4, 5]

for i in range(len(a)):

a = [i + 3 for i in a]

····a[i] += 3

# Или:

a = map(lambda i: i + 3, a)

Используйте функцию enumerate(), чтобы определить свою позицию в списке. Этот вариант выглядит более читаемым, чем создание счетчика, и лучше оптимизирован для итераторов:

>>> a = ["icky", "icky", "icky", "p-tang"]

>>> for i, item in enumerate(a):

… ····print("{i}: {item}".format(i=i, item=item))

…

0: icky

1: icky

2: icky

3: p-tang

Когда логическая строка кода длиннее принятого значения[38], нужно разбить строку на несколько физических строк. Интерпретатор Python объединит следующие друг за другом строки, если последний символ строки — обратный слэш. В некоторых случаях это может оказаться полезным, но такого подхода следует избегать, потому что знак пробела, добавленный в конце строки, разрушит код и может привести к неожиданным последствиям.

Лучшее решение — заключить элементы в круглые скобки. Если интерпретатор Python встретит незакрытую круглую скобку в одной строке, он будет присоединять к ней следующие строки до тех пор, пока скобка не будет закрыта. То же поведение верно для фигурных и квадратных скобок.

french_insult = \

french_insult = (

"Your mother was a hamster, and \

····"Your mother was a hamster, and "

your father smelt of elderberries!"

····"your father smelt of elderberries!"

)

from some.deep.module.in.a.module \

from some.deep.module.in.a.module import (

····import a_nice_function, \

····a_nice_function,

········another_nice_function, \

····another_nice_function,

········yet_another_nice_function

····yet_another_nice_function

)

Однако зачастую необходимость разбивать длинные логические строки указывает на то, что вы пытаетесь выполнить слишком много действий за раз, что может навредить читаемости.

Идиомы

Несмотря на то что обычно существует всего один очевидный способ решить задачу, код Python, написанный с помощью идиом (питонский код), может поначалу казаться неочевидным для новичков (если только они не голландцы[39]). Поэтому вам необходимо освоить хорошие идиомы.

Если вы знаете длину списка или кортежа, можете присвоить имена их элементам с помощью распаковки. Поскольку вы можете указать количество разбиений строки для функций split() и rsplit(), правую сторону выражения присваивания можно разбить только один раз (например, на имя файла и расширение), а левая сторона может содержать оба места назначения одновременно, в правильном порядке. Например, так:

>>> filename, ext = "my_photo.orig.png".rsplit(".", 1)

>>> print(filename, "is a", ext, "file.")

my_photo.orig is a png file.

Вы можете задействовать распаковку для того, чтобы менять местами переменные:

a, b = b, a

Вложенная распаковка также работает:

a, (b, c) = 1, (2, 3)

В Python 3 в PEP 3132 (https://www.python.org/dev/peps/pep-3132/) был представлен новый метод расширенной распаковки:

a, *rest = [1, 2, 3]

# a = 1, rest = [2, 3]

a, *middle, c = [1, 2, 3, 4]

# a = 1, middle = [2, 3], c = 4

Если вам необходимо присвоить какое-то значение во время распаковки, но сама переменная не нужна, воспользуйтесь двойным подчеркиванием (__):

filename = 'foobar.txt'

basename, __, ext = filename.rpartition('.')

Используйте оператор списка Python * для того, чтобы создать список, состоящий из одинаковых неизменяемых элементов:

>>> four_nones = [None] * 4

>>> print(four_nones)

[None, None, None, None]

Одинаковые объекты должны иметь одинаковые значения хэша. В документации к Python содержится более подробная информация.

Однако будьте осторожны при работе с изменяемыми объектами: поскольку списки изменяемы, оператор * создаст список, состоящий из N ссылок на него самого, и это вряд ли вас устроит. Поэтому используйте списковое включение:

>>> four_lists = [[]] * 4

>>> four_lists = [[] for __ in range(4)]

>>> four_lists[0].append("Ni")

>>> four_lists[0].append("Ni")

>>> print(four_lists)

>>> print(four_lists)

[['Ni'], ['Ni'], ['Ni'], ['Ni']]

[['Ni'], [], [], []]

Распространенная идиома для создания строк состоит в том, чтобы использовать функцию str.join() для пустой строки. Данная идиома может быть применена к спискам и кортежам:

>>> letters = ['s', 'p', 'a', 'm']

>>> word = ''.join(letters)

>>> print(word)

spam

Иногда требуется выполнить поиск по коллекции элементов. Изучим два варианта: списки и множества.

Для примера рассмотрим следующий код:

>>> x = list(('foo', 'foo', 'bar', 'baz'))

>>> y = set(('foo', 'foo', 'bar', 'baz'))

>>>

>>> print(x)

['foo', 'foo', 'bar', 'baz']

>>> print(y)

{'foo', 'bar', 'baz'}

>>>

>>> 'foo' in x True

>>> 'foo' in y True

Даже несмотря на то что обе булевых проверки на наличие в списке и множестве выглядят идентично, а foo in y учитывает тот факт, что множества (и словари) в Python являются хэш-таблицами[40], производительность для этих двух примеров будет различной. Python должен пройти по каждому элементу списка в поисках совпадения, на что уходит много времени (это заметно при увеличении размера коллекций). Но поиск ключей во множестве может быть выполнен быстро с помощью поиска по хэшу. Кроме того, множества и словари не могут содержать повторяющихся записей и идентичных ключей. Для получения более подробной информации поинтересуйтесь семинаром на эту тему на ресурсе Stack Overflow (http://stackoverflow.com/questions/513882).

Зачастую блоки try/finally используются для управления ресурсами вроде файлов или блокировок потоков в случае генерации исключений. В PEP 343 (https://www.python.org/dev/peps/pep-0343/) представлены оператор with и протокол управления контекстом (в версиях 2.5 и выше) — идиома, позволяющая заменить блоки try/finally на более читаемый код. Протокол состоит из двух методов, __enter__() и __exit__(), которые при реализации для объекта позволяют использовать этот объект в операторе with, например так:

>>> import threading

>>> some_lock = threading.Lock()

>>>

>>> with some_lock:

… ····# Создать Землю 1, запустить ее на десять миллионов лет…

… ····print(

… ········"Look at me: I design coastlines.\n"

… ········"I got an award for Norway."

… ····)

…

Раньше это выглядело бы так:

>>> import threading

>>> some_lock = threading.Lock()

>>>

>>> some_lock.acquire()

>>> try:

… ····# Создать Землю 1, запустить ее на десять миллионов лет…

… ····print(

… ········"Look at me: I design coastlines.\n"

… ········"I got an award for Norway."

… ····)

… finally:

… ····some_lock.release()

Модуль стандартной библиотеки contextlib (https://docs.python.org/3/library/contextlib.html) предоставляет дополнительные инструменты, которые помогают преобразовать функции в менеджеры контекстов, навязать вызов метода close(), подавить исключения (в Python 3.4 и выше) и перенаправить стандартные потоки вывода и ошибок (в Python 3.4, 3.5 и выше). Рассмотрим пример использования функции contextlib.closing():

>>> from contextlib import closing

>>> with closing(open("outfile.txt", "w")) as output:

… ····output.write("Well, he's…he's, ah…probably pining for the fjords.")

…

56

Но поскольку методы __enter__() и __exit__() определены для объекта, который отвечает за ввод/вывод для файла[41], мы можем использовать это выражение непосредственно, не закрывая файл самостоятельно:

>>> with open("outfile.txt", "w") as output:

····output.write(

········"PININ' for the FJORDS?!?!?!? "

········"What kind of talk is that? look, why did he fall "

········"flat on his back the moment I got 'im home?\n"

····)

…

123

Распространенные подводные камни

По большей части Python — чистый и надежный язык. Однако некоторые ситуации могут быть непонятны для новичков: какие-то из них созданы намеренно, но все равно могут удивить, другие можно считать особенностями языка. В целом все, что продемонстрировано в этом подразделе, относится к неоднозначному поведению, которое может показаться странным на первый взгляд, но впоследствии выглядит разумным (когда вы узнаете о причинах).

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

Что вы написали:

def append_to(element, to=[]):

····to.append(element)

····return to

Чего вы ожидаете:

my_list = append_to(12)

print(my_list)

my_other_list = append_to(42)

print(my_other_list)

Новый список создается всякий раз, когда вызывается функция, если второй аргумент не предоставлен, поэтому результат работы функции выглядит так:

[12]

[42]

Что происходит на самом деле:

[12]

[12, 42]

Новый список создается при определении функции, он же используется в момент каждого последующего вызова: аргументы по умолчанию в Python оцениваются при определении функции, а не при каждом ее вызове (как это происходит, например, в Ruby).

Это означает, что если вы используете изменяемый по умолчанию аргумент и измените его, то он изменится для всех последующих вызовов этой функции.

Что вам нужно сделать вместо этого? Создавайте новый объект при каждом вызове функции, используя аргумент по умолчанию, чтобы показать, что аргумент не был передан (в качестве такого значения подойдет None):

def append_to(element, to=None):

····if to is None:

········to = []

····to.append(element)

····return to

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

def time_consuming_function(x, y, cache={}):

····args = (x, y)

····if args in cache:

········return cache[args]

····# В противном случае функция работает с аргументами в первый раз.

····# Выполняем сложную операцию…

····cache[args] = result

····return result

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

Что вы написали:

def create_multipliers():

····return [lambda x: i * x for i in range(5)]

Чего вы ожидаете:

for multiplier in create_multipliers():

····print(multiplier(2), end="… ")

print()

Список, содержащий пять функций, каждая из них имеет собственную замкнутую переменную i, которая умножается на их аргумент, что приводит к получению следующего результата:

0… 2… 4… 6… 8…

Что происходит на самом деле:

8… 8… 8… 8… 8…

Создаются пять функций, все они умножают х на 4. Почему? В Python замыкания имеют позднее связывание. Это говорит о том, что значения переменных, использованных в замыканиях, определяются в момент вызова внутренней функции.

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

Особенно неудобно то, что вам может показаться, будто ошибка как-то связана с лямбда-выражениями (https://docs.python.org/3/tutorial/controlflow.html#lambda-expressions). Функции, создаваемые с помощью лямбда-выражений, не отличаются от других. Фактически то же самое поведение проявляется и при использовании самого обычного def:

def create_multipliers():

····multipliers = []

····for i in range(5):

········def multiplier(x):

············return i * x

········multipliers.append(multiplier)

····return multipliers

Что вам нужно сделать вместо этого? Наиболее общее решение, возможно, станет «костылем» — временным вариантом устранения проблемы. Из-за уже упомянутого поведения Python, связанного с определением аргументов по умолчанию для функций (см. предыдущий пункт «Изменяемые аргументы функций»), вы можете создать замыкание, которое немедленно связывается со своими аргументами с помощью аргумента по умолчанию:

def create_multipliers():

····return [lambda x, i=i: i * x for i in range(5)]

Помимо этого вы можете использовать функцию functools.partial():

from functools import partial

from operator import mul

def create_multipliers():

····return [partial(mul, i) for i in range(5)]

Когда подводный камень вовсе не подводный камень. Иногда нужно, чтобы замыкания вели себя подобным образом. Позднее связывание может быть полезным во многих ситуациях (например, в проекте Diamond, см. пункт «Пример использования замыкания (когда подводный камень вовсе не подводный камень)» на с. 136). Наличие уникальных функций в циклах, к сожалению, может привести к сбоям.

Под структурированием мы понимаем решения, которые вы принимаете по поводу функционирования вашего проекта. Его цель состоит в использовании возможностей Python для создания чистого и эффективного кода. На практике это означает, что логика и зависимости в коде и структуре файлов и каталогов прозрачны.

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

В книге Python Cookbook есть глава, посвященная модулям и пакетам (http://bit.ly/python-cookbook-ch10), в которой подробно описывается, как работают выражения __import__ и упаковка. Цель этого раздела — осветить основные аспекты системы модулей и импортирования Python, необходимые для структурирования ваших проектов. Далее мы рассмотрим разные подходы к сборке кода, который легко будет расширять и тестировать.

Благодаря тому, как в Python налажен процесс импортирования и разбиения на модули, структурировать проект довольно просто: существует всего несколько ограничений, модель для импортирования также нетрудно освоить. Поэтому перед вами стоит исключительно архитектурная задача — создать различные части проекта и продумать их взаимодействие.

Модули

Модуль — это один из основных уровней абстракции в Python. Уровни абстракции позволяют программисту разбивать код на части, которые содержат связанные данные и функциональность.

Например, если один уровень проекта предназначен для взаимодействия с пользователем, а другой обрабатывает данные на низком уровне, наиболее логичным способом разделения этих двух слоев является размещение всей функциональности, связанной со взаимодействием, в одном файле, а всех низкоуровневых операций — в другом. Такая группировка разметит их в два разных модуля. Файл для взаимодействия затем импортирует файл для низкоуровневой обработки с помощью выражения import module или from module import attribute.

Как только вы пустите в ход выражение import, вы начнете пользоваться модулями. Модули могут быть либо встроенными (вроде os и sys), либо сторонними пакетами, установленными в среде (вроде Requests или NumPy), либо внутренними модулями проекта.

Далее показан пример некоторых выражений import (подтверждается, что импортированный модуль является объектом Python со своим типом данных):

>>> import sys # built-in module

>>> import matplotlib.pyplot as plt # сторонний модуль

>>>

>>> import mymodule as mod # внутренний модуль проекта

>>>

>>> print(type(sys), type(plt), type(mod))

В соответствии с руководством по стилю кода (https://www.python.org/dev/peps/pep-0008/) присваивайте модулям короткие имена, которые начинаются со строчной буквы. И убедитесь, что не использовали специальные символы вроде точки (.) или вопросительного знака (?), поскольку это может нарушить вид Python для модулей. Поэтому вам следует избегать имен файла вроде my.spam.py[42] (Python попытается найти файл spam.py в каталоге с именем my, а это неверно). В документации Python (http://docs.python.org/tutorial/modules.html#packages) более подробно описывается нотация с точкой.

Импортирование модулей. Помимо следования некоторым ограничениям в именовании, для использования файла Python в качестве модуля не требуется больше ничего особенного. Однако понимать механизм импортирования будет нелишним. Во-первых, выражение import modu начнет искать определение modu в файле с именем modu.py в том же каталоге, где находится и вызывающая сторона, если такой файл существует. При неудаче интерпретатор Python будет рекурсивно искать файл modu.py в пути поиска Python (https://docs.python.org/2/library/sys.html#sys.path) и сгенерирует исключение ImportError, если не найдет. Путь поиска зависит от платформы и включает в себя определенные пользователем или системой каталоги, указанные в переменной среды $PYTHONPATH (или %PYTHONPATH% в Windows). Ее можно просмотреть или изменить в сессии Python:

import sys

>>> sys.path

['', '/current/absolute/path', 'etc']

# Реальный список содержит каждый путь, где выполняется поиск,

# когда вы импортируете библиотеки в Python в том порядке,

# в котором они проверяются.

Как только файл modu.py будет найден, интерпретатор Python запустит модуль в ограниченной области видимости. Любое выражение верхнего уровня в файле modu.py будет выполнено, включая другие выражения импорта, если таковые существуют. Определения функций и классов хранятся в словаре модуля. Наконец, переменные функции и классы модуля будут доступны вызывающей стороне с помощью пространства имен модуля — основной концепции программирования, которая особенно эффективна в Python. Пространства имен предоставляют область видимости, содержащую именованные атрибуты, которые видны друг другу, но к ним нельзя получить доступ из-за пределов пространства имен.

Во многих языках директива заставляет препроцессор, по сути, скопировать содержимое включаемого файла в код вызывающей стороны. В Python все происходит иначе: включаемый код изолируется в пространстве имен модуля. Результатом выполнения выражения import modu станет объект модуля с именем modu, который будет находиться в глобальном пространстве имен, его атрибуты будут доступны с помощью точечной нотации. Например modu.sqrt — это объект sqrt, определенный внутри файла modu.py. Это означает, что вам, как правило, не нужно волноваться о том, что включаемый код может делать что-то нежелательное, к примеру переопределять существующую функцию с тем же именем.

Вы можете симулировать более привычное поведение, используя специальный синтаксис в выражении import: from modu import *. Однако это, как правило, считается признаком плохого тона: наличие конструкции import * усложняет чтение кода, делает зависимости более связанными и может затереть (перезаписать) существующие определенные объекты новыми описаниями из импортированного модуля.

Нотация from modu import func — это способ импортировать только необходимые вам атрибуты в глобальное пространство имен. Она гораздо безопаснее нотации from modu import *, поскольку явно показывает, что именно импортируется в глобальное пространство имен. Единственное ее преимущество перед более простой нотацией import modu в том, что она сэкономит вам немного времени.

В табл. 4.1 сравниваются разные способы импортирования определений из других модулей.

Как упоминается в разделе «Стиль кода» в начале этой главы, читаемость — одна из основных особенностей Python. Читаемый код не содержит бесполезного текста. Но не следует максимально его сокращать в угоду краткости. Явно указывая, откуда появился тот или иной класс или функция, как в случае идиомы modu.func(), вы повышаете читаемость кода и степень его понимания.

Упаковка

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

Любой каталог, содержащий файл __init__.py, считается пакетом Python. Каталог высшего уровня, в котором находится файл __init__.py, является корневым пакетом[43]. Разные модули пакетов импортируются аналогично простым модулям, но файл __init__.py при этом будет использован для сбора всех описаний на уровне пакета.

Файл modu.py, находящийся в каталоге pack/, импортируется с помощью выражения import pack.modu. Интерпретатор выполнит поиск файла __init__.py в pack и запустит все его выражения верхнего уровня. Затем выполнит поиск файла с именем pack/modu.py и запустит все его выражения верхнего уровня. После этих операций любая переменная, функция или класс, определенные в файле modu.py, будут доступны пространству имен pack.modu.

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

Признаком хорошего тона является поддержание файла __init__.py пустым, когда модули и подпакеты пакета не имеют общего кода. Проекты HowDoI и Diamond, использованные в качестве примеров в следующем разделе, не содержат кода в файлах __init__.py, помимо номеров версий. В проектах Tablib, Requests и Flask в этом файле есть строка документации верхнего уровня и выражения импорта, предоставляющие API каждого проекта. Проект Werkzeug также предоставляет API верхнего уровня, но делает это с помощью ленивой загрузки (дополнительного кода, который добавляет содержимое в пространство имен, только когда тот используется, что ускоряет работу исходного выражения импорта).

Наконец, для импортирования глубоких вложенных пакетов доступен удобный синтаксис: import very.deep.module as mod. Это позволяет использовать слово mod на месте избыточной конструкции very.deep.module.

Объектно-ориентированное программирование

Python иногда описывается как объектно-ориентированный язык. Это может вносить путаницу, поэтому давайте проясним данный вопрос.

В Python все элементы являются объектами и могут быть обработаны как объекты. Именно это мы имеем в виду, когда говорим, что функции являются объектами первого класса. Функции, классы, строки и даже типы считаются в Python объектами: все они имеют тип, их можно передать как аргументы функций, они могут иметь методы и свойства. С этой точки зрения Python действительно объектно-ориентированный язык.

Однако, в отличие от Java, в Python парадигма объектно-ориентированного программирования не будет основной. Проект, написанный на Python, вполне может быть не объектно-ориентированным, то есть в нем не будут использоваться (или будут, но в небольших количествах) определения классов, наследование классов или другие механизмы, характерные для объектно-ориентированного программирования. Для питонистов эта функциональность доступна, но необязательна. Более того, как вы могли увидеть в подразделе «Модули» текущего раздела, способ, с помощью которого Python обрабатывает модули и пространства имен, дает разработчику возможность гарантировать инкапсуляцию и разделение между абстрактными уровнями — наиболее распространенную причину использования парадигмы объектно-ориентированного программирования — без наличия классов.

Защитники функционального программирования (парадигма, которая в своей чистейшей форме не имеет операторов присваивания и побочных эффектов и вызывает функции одну за другой, чтобы выполнить задачу) могут утверждать: из-за того, что функция выполняет разную работу в зависимости от состояния системы (например, от глобальной переменной, которая указывает, вошел ли пользователь под своей учетной записью), могут возникать ошибки и путаница. В Python (несмотря на то что он не является чисто функциональным языком) имеются инструменты, которые позволяют заниматься функциональным программированием (http://bit.ly/functional-programming-python). Мы можем ограничить применение пользовательских классов до ситуаций, когда понадобится объединить состояние и функциональность.

В некоторых архитектурах, обычно в веб-приложениях, создается несколько процессов Python для того, чтобы реагировать на внешние запросы, которые могут происходить одновременно. В этом случае сохранение состояния созданных объектов (означает хранение статичной информации о мире) может привести к состоянию гонки. Этот термин употребляется при описании ситуации, когда в какой-то момент между инициализацией состояния объекта (которая в Python выполняется с помощью метода Class.__init__()) и использованием его состояния с помощью одного из методов состояние мира изменилось.

Например, запрос может загрузить предмет в память и затем пометить, что он добавлен в корзину пользователя. Если другой запрос в то же время «продаст» такой же предмет другому человеку, может случиться, что продажа на самом деле произойдет после того, как первая сессия добавит предмет (затем мы попытаемся продать предмет, который уже помечен как проданный). Подобные проблемы приводят к тому, что многие предпочитают функции, не сохраняющие состояние.

Мы дадим следующую рекомендацию: при работе с кодом, полагающимся на некий устойчивый контекст или глобальное состояние (как и многие веб-приложения), используйте функции и процедуры, которые привнесут минимальное количество неявных контекстов и побочных эффектов. Неявный контекст функции создается из любых глобальных переменных и элементов на уровне сохраняемости, к которым можно получить доступ из функции. Побочные эффекты — это изменения, которые функция вносит в свой неявный контекст. Если функция сохраняет или удаляет данные в глобальной переменной или на уровне сохраняемости, можно сказать, что она имеет побочные эффекты.

Пользовательские классы в Python необходимо применять для того, чтобы аккуратно изолировать функции, имеющие контексты и побочные эффекты, от функций, которые имеют логику (называются чистыми функциями). Чистые функции всегда определены: учитывая фиксированные входные данные, результат их работы неизменен, потому что они не зависят от контекста и не имеют побочных эффектов. Функция print(), например, не является чистой, поскольку ничего не возвращает, а записывает данные в стандартный поток ввода-вывода как побочный эффект.

Рассмотрим преимущества чистых функций:

• их проще изменить или заменить, если нужно выполнить рефакторинг;

• их проще тестировать с помощью юнит-тестов, не нужно выполнять сложную настройку контекста и очищать данные после ее работы;

• ими проще манипулировать, их легче декорировать (к этой теме мы сейчас вернемся) и передавать.

В итоге для некоторых инфраструктур чистые функции выступают более эффективными строительными блоками, чем классы или объекты, поскольку не имеют контекста и побочных эффектов. В качестве примера рассмотрим функции ввода-вывода, связанные с каждым форматом файла в библиотеке Tablib (tablib/formats/*.py — мы опишем Tablib в следующей главе). Они являются чистыми функциями, а не частью класса, поскольку лишь считывают данные из отдельного объекта типа Dataset, в котором хранятся, либо записывают объект типа Dataset в файл. Но объект типа Session в библиотеке Requests (ее мы также рассмотрим в следующей главе) — это класс, поскольку он должен сохранять cookies и информацию об аутентификации, которая может пригодиться при обмене данными в ходе сессии HTTP.

Декораторы

Декораторы были добавлены в Python в версии 2.4, определены и рассмотрены в PEP 318 (https://www.python.org/dev/peps/pep-0318/). Декоратор — это функция или метод класса, которые оборачивают (или декорируют) другую функцию или метод. Декорированная функция или метод заменят оригинал. Поскольку функции являются объектами первого класса в Python, декорирование можно выполнить вручную, но все же более предпочтителен синтаксис @decorator. Рассмотрим пример использования декоратора:

>>> def foo():

… ····print("I am inside foo.")

…

…

…

>>> import logging

>>> logging.basicConfig()

>>>

>>> def logged(func, *args, **kwargs):

… ····logger = logging.getLogger()

… ····def new_func(*args, **kwargs):

… ········logger.debug("calling {} with args {} and kwargs {}".format(

… ···················· func.__name__, args, kwargs))

… ········return func(*args, **kwargs)

… ····return new_func

…

>>>

>>>

… @logged

… def bar():

… ····print("I am inside bar.")

…

>>> logging.getLogger(). setLevel(logging.DEBUG)

>>> bar()

DEBUG: root: calling bar with args () and kwargs {}

I am inside bar.

>>> foo()

I am inside foo.

Этот механизм подойдет, чтобы изолировать основную логику функции или метода. Примером задачи, для которой нужно использовать декорирование, можно назвать запоминание или кэширование: вы хотите сохранить результат дорогой функции в таблице и использовать его вместо того, чтобы выполнять повторные вычисления. Очевидно, это не является частью логики функции. В PEP 3129 (https://www.python.org/dev/peps/pep-3129/), начиная с Python 3, декораторы также можно применять к классам.

Динамическая типизация

Python — динамически типизированный язык (в противоположность статически типизированным). Это означает, что переменные не имеют фиксированного типа. Переменные реализуются как указатели на объект, что дает возможность задать сначала значение 42, затем значение thanks for all the fish, а потом установить в качестве значения функцию.

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

a = 1

def get_answer(a):

a = 'answer is {}'.format(a)

····return 'answer is

····{}'.format(a)

a = get_answer(1)

# Строка…

items_string = 'a b c d'

items = 'a b c d'

items_list = items.split(' ')

# А теперь список

items = set(items_list)

items = items.split(' ')

# А теперь множество

items = set(items)

Повторное использование имен не повышает эффективность: операция присваивания все равно создаст новый объект. При росте сложности, когда операции присваивания разделены другими строками кода, сложно определить тип переменной.

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

Изменяемые и неизменяемые типы

В Python имеются два типа встроенных или определяемых пользователем[44] типов:

# Списки можно изменять

my_list = [1, 2, 3]

my_list[0] = 4

print my_list # [4, 2, 3] <- тот же список, измененный.

# Целые числа изменять нельзя

x = 6

x = x + 1 # Новое значение x занимает другое место в памяти.

• Изменяемые типы. Позволяют изменять содержимое объекта на месте. Примерами могут стать списки и словари, которые имеют изменяющие методы вроде list.append() или dict.pop() и могут быть модифицированы на месте.

• Неизменяемые типы. Не предоставляют методов для изменения их содержимого. Например, переменная х со значением 6 не имеет метода для инкремента. Для того чтобы вычислить значение выражения х + 1, нужно создать другую целочисленную переменную и дать ей имя.

Одно из последствий такого поведения — объекты изменяемых типов не могут быть использованы как ключи для словаря, ведь если их значение изменится, то изменится и его хэш (словари используют хэширование[45] для хранения ключей). Неизменяемым эквивалентом списка является кортеж. Он создается добавлением круглых скобок, например (1, 2). Кортеж нельзя изменить на месте, поэтому его можно использовать как ключ словаря.

Правильное применение изменяемых типов для объектов, которые по задумке должны изменяться (например, my_list = [1, 2, 3]), и неизменяемых типов для объектов, которые по задумке должны иметь фиксированное значение (например, islington_phone = ("220", "7946", "0347")), поможет другим разработчикам понять код.

В Python строки неизменяемы и это может удивить новичков. Попытка изменить строку вызовет ошибку:

>>> s = "I'm not mutable"

>>> s[1:7] = " am"

Traceback (most recent call last):

File "", line 1, in 

TypeError: 'str' object does not support item assignment

Это означает, что при создании строки по частям гораздо эффективнее собрать все части в список, поскольку его можно изменять, а затем объединить их. Кроме того, в Python предусмотрены списковые включения, которые предоставляют простой синтаксис для итерирования по входным данным для создания списка. В табл. 4.3 приведены способы создания строки из итерабельного объекта.

>>> s = ""

>>> s = []

>>> r = (97, 98, 99)

>>> for c in (97, 98, 98):

>>> for c in (97, 98, 99):

>>> s = [unichr(c) for

… ····s += unichr(c)

… ····s.append(unichr(c))

····c in r]

…

…

>>> print("".join(s))

>>> print(s)

>>> print("".join(s))

abc

abc

abc

На главной странице Python (https://www.python.org/doc/essays/list2str/) вы можете найти обсуждение подобной оптимизации.

Наконец, если количество элементов конкатенации известно, добавить строку будет проще (и очевиднее), чем создавать список элементов только для того, чтобы вызвать функцию "".join().

Все следующие варианты форматирования для определения переменной cheese делают одно и то же[46]:

>>> adj = "Red"

>>> noun = "Leicester"

>>>

>>> cheese = "%s %s" % (adj, noun) # Этот стиль устарел (PEP 3101)

>>> cheese = "{} {}".format(adj, noun) # Возможно начиная с Python 3.1

>>> cheese = "{0} {1}".format(adj, noun) # Числа можно использовать повторно

>>> cheese = "{adj} {noun}".format(adj=adj, noun=noun) # Этот стиль — лучший

>>> print(cheese)

Red Leicester

Зависимости, получаемые от третьей стороны

Пакет, который использует зависимости, получаемые от третьей стороны, содержит внешние зависимости (сторонние библиотеки) внутри своего исходного кода, зачастую внутри каталога с именем vendor или packages. По адресу http://bit.ly/on-vendorizing вы можете прочесть весьма полезную статью, в которой перечисляются основные причины, почему владелец пакета может воспользоваться зависимостями третьей стороны (в основном для того, чтобы избежать проблем с совместимостью), а также рассматриваются альтернативные подходы.

Однако можно достичь консенсуса: почти во всех случаях лучше всего держать зависимости отдельно друг от друга, поскольку это добавляет ненужное содержимое (зачастую мегабайты дополнительного кода) в репозиторий. Виртуальные среды, использованные в сочетании с файлами setup.py (предпочтительно, особенно если пакет является библиотекой) или requirements.txt (при использовании переопределит зависимости в файле setup.py в случае конфликтов), могут ограничить зависимости набором рабочих версий.

Если этих вариантов недостаточно, можно связаться с владельцем зависимости, чтобы решить проблему, обновив его пакет (например, ваша библиотека может зависеть от выходящего релиза его пакета или вам нужна новая функциональность). Эти изменения, скорее всего, пойдут на пользу всему сообществу. Однако здесь имеется и подводный камень: если вы отправите запрос на включение больших изменений, вам, возможно, придется поддерживать эти изменения по мере появления дальнейших предложений и запросов (по этой причине в проектах Tablib и Requests несколько зависимостей получены от третьей стороны). По мере полного перехода сообщества на Python 3 мы надеемся, что проблемных областей станет меньше.

Тестировать код очень важно. Ведь люди будут использовать только такой проект, который на самом деле работает.

Модули doctest и unittest впервые появились в версии Python 2.1 (выпущена в 2001 году), поддерживая разработку через тестирование (test-driven development, TDD): разработчик сначала пишет тесты, которые определяют основную задачу и узкие места функции, а затем — функцию, которая проходит эти тесты. С тех пор TDD стали чаще использовать в бизнес-проектах и проектах с открытым исходным кодом — практиковаться в написании кода теста и параллельно самой функции довольно полезно. Если пользоваться этим методом с умом, он поможет вам четко определить предназначение своего кода и создать развернутую модульную структуру.

Тест — это самый объемный фрагмент кода, который автостопщик может написать. Приведем несколько советов.

Тестируйте что-то одно за раз. Юнит-тест должен концентрироваться на небольшом фрагменте функциональности и доказывать, что все работает, как требуется.

Независимость императивна. Каждый юнит-тест должен быть полностью независимым: его можно запустить как отдельно, так и внутри набора тестов без учета того, в каком порядке они вызываются. Из этого правила следует, что для каждого теста нужно загрузить свежий набор данных, а после его выполнения провести очистку (обычно с помощью методов setUp() и tearDown()).

Точность лучше простоты. Используйте длинные описательные имена для функций теста. Это правило отличается от правила для рабочего кода, где предпочительны короткие имена. Причина в том, что функции никогда не вызываются явно. В рабочем коде допускается использование имен square() или даже sqr(), но в коде теста у вас должны быть имена вроде test_square_of_number_2() или test_square_negative_number(). Эти имена функций будут выведены, когда тест даст сбой, они должны быть максимально описательными.

Скорость имеет значение. Старайтесь писать тесты, которые работают быстро. Если для того, чтобы тест отработал, нужно несколько миллисекунд, разработка будет замедлена или тесты будут запускаться не так часто, как вам бы этого хотелось. В некоторых случаях тесты не могут быть быстрыми, поскольку для их работы требуется сложная структура данных, которая должна подгружаться каждый раз, когда запускается тест. Держите подобные тесты в отдельном наборе, который запускается какой-нибудь задачей по графику, а остальные тесты запускайте так часто, как вам это нужно.

RTMF (Read the manual, friend! — «Читай руководство, друг!»). Изучайте свои инструменты, чтобы знать, как запустить отдельный тест или набор тестов. При разработке функции внутри модуля почаще запускайте тесты для нее, в идеале всякий раз, когда вы сохраняете код.

Тестируйте все в начале работы и затем опять тестируйте по ее завершении. Всегда запускайте полный набор тестов перед тем, как писать код, и по завершении работы. Это позволит убедиться, что вы ничего «не сломали» в остальной части кода.

Автоматические функции перехвата для системы управления версиями фантастически хороши. Реализовать функцию перехвата, которая запускает все тесты перед тем, как отправить код в общий репозиторий, — хорошая идея. Вы можете непосредственно добавлять функции перехвата в вашу систему контроля версий, некоторые IDE предоставляют способы сделать это с помощью их собственных сред. Далее приведены ссылки на документацию к популярным системам контроля версий, в которой содержится информация о том, как это реализовать:

• GitHub (https://developer.github.com/webhooks/);

• Mercurial (http://bit.ly/mercurial-handling-repo);

• Subversion (http://bit.ly/svn-repo-hook).

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

В случае неопределенности выполните отладку для теста. Первый шаг отладки кода — написание еще одного теста, который указывает на ошибку. Несмотря на то что это не всегда можно сделать, тесты, отлавливающие ошибки, являются наиболее ценными фрагментами кода вашего проекта.

Если тест сложно объяснить, то желаем вам удачи в поиске коллег. Если что-то идет не так или что-то нужно изменить и для вашего кода написано множество тестов, вы или другие сотрудники, работающие над проектом, будете полагаться на набор тестов для решения проблемы или изменения поведения. Поэтому код теста должен быть читаемым на том же уровне (или даже больше), чем рабочий код. Юнит-тест, чье предназначение неясно, не принесет большой пользы.

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

Не паникуйте! Это же ПО с открытым исходным кодом! Вас поддержит весь мир.

Основы тестирования

В этом разделе приводятся основы тестирования, чтобы у вас было представление о доступных вариантах, и примеры из проектов Python, которые мы рассмотрим в главе 5. Есть целая книга, посвященная TDD в Python, мы не хотим переписывать ее здесь. Она называется Test-Driven Development with Python (издательство O’Reilly).

unittest — это тестовый модуль стандартной библиотеки Python, готовый к работе сразу после установки. Его API будет знаком всем, кто пользовался любым из этих инструментов — JUnit (Java)/nUnit (.NET)/CppUnit (C/C++).

Создать тест в этом модуле можно путем создания подкласса для unittest.TestCase. В этом примере функция тестирования определяется как новый метод в MyTest:

# test_example.py

import unittest

def fun(x):

····return x + 1

class MyTest(unittest.TestCase):

····def test_that_fun_adds_one(self):

········self.assertEqual(fun(3), 4)

class MySecondTest(unittest.TestCase):

····def test_that_fun_fails_when_not_adding_number(self):

········self.assertRaises(TypeError, fun, "multiply six by nine")

Для того чтобы запустить все тесты в TestClass, откройте терминальную оболочку. Находясь в том же каталоге, где файл, вызовите из командной строки модуль unittest:

$ python — m unittest test_example.MyTest

.

---

Ran 1 test in 0.000s

OK

Для запуска всех тестов из файла укажите файл:

$ python — m unittest test_example

.

---

Ran 2 tests in 0.000s

OK

В версии Python 3.3 unittest.mock (https://docs.python.org/dev/library/unittest.mock) доступен в стандартной библиотеке. Он позволяет заменять тестируемые части системы mock-объектами и делать предположения о том, как они используются.

Например, вы можете написать обезьяний патч для метода, похожий на тот, что показан в предыдущем примере (обезьяний патч — это код, который модифицирует или заменяет другой существующий код во время работы программы). В этом коде существующий метод с именем ProductionClass.method (в случае если мы создали именованный объект) заменяется новым объектом MagicMock, который при вызове всегда будет возвращать значение 3. Кроме того, этот объект считает количество получаемых вызовов, записывает сигнатуру, с помощью которой был вызван, и содержит методы с выражением, необходимые для тестов:

from unittest.mock import MagicMock

instance = ProductionClass()

instance.method = MagicMock(return_value=3)

instance.method(3, 4, 5, key='value')

instance.method.assert_called_with(3, 4, 5, key='value')

Для того чтобы создавать mock-классы и объекты при тестировании, используйте декоратор patch. В следующем примере поиск во внешней системе заменяется mock-объектом, который всегда возвращает одинаковый результат (патч существует только во время работы теста):

import unittest.mock as mock

def mock_search(self):

····class MockSearchQuerySet(SearchQuerySet):

········def __iter__(self):

············return iter(["foo", "bar", "baz"])

····return MockSearchQuerySet()

# SearchForm относится к ссылке на импортированный класс

# myapp.SearchForm и модифицирует этот объект, но не код,

# где определяется сам класс SearchForm

@mock.patch('myapp.SearchForm.search', mock_search)

def test_new_watchlist_activities(self):

····# get_search_results выполняет поиск и итерирует по результату

····self.assertEqual(len(myapp.get_search_results(q="fish")), 3)

Вы можете сконфигурировать модуль mock и управлять его поведением разными способами. Они подробно описаны в документации к unittest.mock.

Модуль doctest выполняет поиск фрагментов текста, которые похожи на интерактивные сессии Python в строках документации, а затем выполняет эти сессии, чтобы убедиться, что они работают именно так, как было показано.

Модуль doctest служит другой цели, нежели юнит-тесты. Они обычно менее детальны и не отлавливают особые случаи или регрессионные ошибки. Вместо этого они выступают в качестве содержательной документации основных вариантов использования модуля и его компонентов (в качестве примера можно рассмотреть сценарий «счастливый путь» (happy path — https://en.wikipedia.org/wiki/Happy_path)). Однако такие тесты должны запускаться автоматически каждый раз, когда запускается весь набор тестов.

Рассмотрим простой пример doctest:

def square(x):

····"""Squares x.

····>>> square(2)

····4

····>>> square(-2)

····4

····"""

····return x * x if __name__ == '__main__':

····import doctest

····doctest.testmod()

Когда вы запускаете этот модуль из командной строки (например, с помощью команды python module.py), такие тесты начнут выполняться и «пожалуются», если какой-то компонент ведет себя не так, как описано в строках документации.

Примеры

В этом разделе мы рассмотрим фрагменты наших любимых пакетов для того, чтобы подчеркнуть правила хорошего тона при тестировании реального кода. Набор тестов предполагает наличие дополнительных библиотек, не включенных в эти пакеты (например, для Requests требуется Flask, чтобы создать mock-сервер HTTP), которые включены в файлы requirements.txt их проектов.

Для всех этих примеров ожидаемым первым шагом будет открытие терминальной оболочки, изменение каталогов таким образом, чтобы они указывали на то место, где лежат исходники к вашим проектам, а также клонирование репозитория исходного кода и настройка виртуальной среды. Например, так:

$ git clone https://github.com/username/projectname.git

$ cd projectname

$ virtualenv — p python3 venv

$ source venv/bin/activate

(venv)$ pip install — r requirements.txt

Tablib использует модуль unittest стандартной библиотеки Python. Набор тестов не поставляется с пакетом. Для получения файлов вы должны клонировать репозиторий GitHub. Приводим основные моменты, выделив главные части.

Для того чтобы использовать юнит-тест, создайте подкласс unittest.TestCase и напишите методы для тестирования, чьи имена начинаются с test. Класс TestCase предоставляет методы с выражением, которые позволяют выполнить проверку на равенство, правдивость, тип данных и наличие исключений (см. документацию по адресу http://bit.ly/unittest-testcase для получения более подробной информации).

Метод TestCase.setUp() запускается всякий раз перед каждым методом TestCase.

Метод TestCase.tearDown() запускается всякий раз после каждого метода TestCase[47].

Все имена тестов должны начинаться со слова test, иначе они не запустятся.

В одном тестовом случае может быть несколько тестов, но каждый из них должен тестировать что-то одно.

Если вы хотите внести вклад в Tablib, первое, что можете сделать после клонирования репозитория, — запустить набор тестов и убедиться, что все работает как полагается. Это можно сделать так:

(venv)$ ### внутри каталога высшего уровня, tablib/

(venv)$ python — m unittest test_tablib.py

……………………………………………………..

---

Ran 62 tests in 0.289s

OK

В версии Python 2.7 метод unittest также содержит собственный механизм обнаружения тестов, который доступен с помощью параметра discover в командной строке:

(venv)$ ### *above* the top-level directory, tablib/

(venv)$ python — m unittest discover tablib/

……………………………………………………..

---

Ran 62 tests in 0.234s

OK

После того как вы убедитесь, что все тесты проходят, вы: а) найдете тестовый случай, связанный с изменяемой частью проекта, и будете часто запускать его при изменении кода; б) напишете новый тестовый случай для функциональности, которую хотите добавить, или для ошибки, которую отслеживаете, и будете часто запускать его при изменении кода. Рассмотрим в качестве примера следующий сниппет:

(venv)$ ### внутри каталога высшего уровня, tablib/

(venv)$ python — m unittest test_tablib.TablibTestCase.test_empty_append

.

---

Ran 1 test in 0.001s

OK

Как только ваш код начнет работать, снова задействуйте весь набор тестов перед тем, как отправить его в репозиторий. Поскольку вы часто запускаете тесты, они должны быть максимально быстрыми. Более подробную информацию о том, как использовать метод unittest, смотрите в документации по адресу http://bit.ly/unittest-library.

Пакет Requests использует py.test. Чтобы увидеть его в действии, откройте терминальную оболочку, перейдите во временный каталог, клонируйте Requests, установите все зависимости и запустите файл py.test, как показано здесь:

$ git clone — q https://github.com/kennethreitz/requests.git

$

$ virtualenv venv — q — p python3 # dash — q for 'quiet'

$ source venv/bin/activate

(venv)$

(venv)$ pip install — q — r requests/requirements.txt # 'quiet' again…

(venv)$ cd requests

(venv)$ py.test

========================= test session starts =================================

platform darwin — Python 3.4.3, pytest-2.8.1, py-1.4.30, pluggy-0.3.1

rootdir: /tmp/requests, inifile:

plugins: cov-2.1.0, httpbin-0.0.7

collected 219 items

tests/test_requests.py………………………………………………..

X……………………………………..

tests/test_utils.py..s…………………………………………….

========= 217 passed, 1 skipped, 1 xpassed in 25.75 seconds ===================

Другие популярные инструменты

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

pytest (http://pytest.org/latest/) — это нешаблонная альтернатива модуля стандартной библиотеки Python. Это означает, что для него не требуется создавать временные платформы для тестовых случаев и, возможно, даже не нужны методы установки и очистки. Для установки запустите команду pip в обычном режиме:

$ pip install pytest

Несмотря на то что инструмент тестирования имеет множество возможностей и его можно расширять, синтаксис остается довольно простым. Создать набор тестов так же просто, как и написать модуль с несколькими функциями:

# содержимое файла test_sample.py

def func(x):

····return x + 1

def test_answer():

····assert func(3) == 5

После этого вам лишь нужно вызвать команду py.test. Сравните это с работой, которая потребуется для создания эквивалентной функциональности с помощью модуля unittest:

$ py.test

=========================== test session starts ============================

platform darwin — Python 2.7.1 — pytest-2.2.1

collecting… collected 1 items

test_sample.py F

================================= FAILURES =================================

_______________________________ test_answer ________________________________

····def test_answer():

> ····assert func(3) == 5

E ····assert 4 == 5

E ····+ where 4 = func(3)

test_sample.py:5: AssertionError

========================= 1 failed in 0.02 seconds =========================

Nose (http://readthedocs.org/docs/nose/en/latest/) расширяет unittest для того, чтобы упростить тестирование:

$ pip install nose

Предоставляет возможность автоматически обнаруживать тесты, чтобы сэкономить ваше время и избавить от необходимости создавать наборы тестов вручную. Предлагает множество надстроек для дополнительной функциональности вроде совместимого с xUnit вывода тестов, отчетов о покрытии, а также выбора тестов.

tox (http://testrun.org/tox/latest/) — инструмент для автоматизирования управления средами тестирования и для тестирования в разных конфигурациях интерпретатора:

$ pip install tox

tox позволяет сконфигурировать сложные матрицы тестов с большим количеством параметров с помощью конфигурационного файла, похожего на INI-файлы.

Если вы не можете контролировать свою версию Python, но хотите использовать эти инструменты тестирования, предлагаем вам несколько вариантов.

unittest2. Это обратный порт модуля unittest (http://pypi.python.org/pypi/unittest2) для версии Python 2.7, который имеет усовершенствованный API и лучшие выражения относительно тех, что были доступны в предыдущих версиях Python.

Если вы используете Python 2.6 или ниже (например, если вы работаете в крупном банке или компании Fortune 500), можете установить его с помощью команды pip:

$ pip install unittest2

Вы можете захотеть импортировать модуль под именем unittest, чтобы вам было проще портировать код на новые версии модуля в будущем:

import unittest2 as unittest

class MyTest(unittest.TestCase):

····…

Таким образом, если вы когда-нибудь перейдете на новую версию Python и вам больше не потребуется модуль unittest2, вы сможете изменить выражение импорта, не меняя остальной код.

Mock. Если вам понравилось то, что вы прочитали в пункте «Mock (в модуле unittest)» раздела «Основы тестирования» выше, но вы работаете с Python в версии ниже 3.3, вы все еще можете использовать unittest.mock, импортировав его как отдельную библиотеку:

$ pip install mock

fixture. Предоставляет инструменты, которые позволяют проще настраивать и очищать бэкенды баз данных для тестирования (http://farmdev.com/projects/fixture/). Он может загружать фальшивые наборы данных для использования в SQLAlchemy, SQLObject, Google Datastore, Django ORM и Storm. Существуют и его новые версии, но его тестировали только для версий Python 2.4–2.6.

Lettuce и Behave — это пакеты для выполнения разработки через реализацию поведения (behavior-driven development, BDD) в Python. BDD — процесс, который появился на основе TDD в начале 2000-х годов для того, чтобы заменить слово «тест» в TDD на слово «поведение» (дабы преодолеть проблемы, возникающие у новичков при освоении TDD). Это название появилось благодаря Дэну Норту (Dan North) в 2003-м и было представлено миру наряду с инструментом JBehave для Java в статье 2006 года в журнале Better Socware (представляла собой отредактированную статью из блога Дэна Норта Introducing BDD по адресу http://dannorth.net/introducing-bdd).

Концепция BDD набрала популярность после того, как в 2011 году вышла книга 6e Cucumber Book (Pragmatic Bookshelf), где был задокументирован пакет Behave для Ruby. Это вдохновило Гэбриэла Фалько (Gabriel Falco) на создание Lettuce (http://lettuce.it/), а Питера Паренте (Peter Parente) — на создание Behave (http://pythonhosted.org/behave/) для нашего сообщества.

Поведения описываются простым текстом с помощью синтаксиса под названием Gherkin, который люди могут прочитать, а машины — понять. Вам могут пригодиться следующие руководства:

• руководство по Gherkin (https://github.com/cucumber/cucumber/wiki/Gherkin);

• руководство по Lettuce (http://lettuce.it/tutorial/simple.html);

• руководство по Behave (http://tott-meetup.readthedocs.org/en/latest/sessions/behave.html).

Читаемость — главная цель разработчиков Python как в проектах, так и в документации. Приемы, описанные в этом разделе, помогут вам сэкономить немало времени.

Документация к проекту

Существует документация по API, предназначенная пользователям проектов, а также дополнительная документация для тех, кто хочет вносить в проект свой вклад. В этом разделе вы узнаете о дополнительной документации.

Файл README, расположенный в корневом каталоге, призван давать общую информацию как пользователям, так и тем, кто обслуживает проект. В нем должен быть либо простой текст, либо легкая для чтения разметка вроде reStructured Text (сейчас это единственный формат, который понимает PyPI[48]) или Markdown (https://help.github.com/articles/basic-writing-and-formatting-syntax/). Этот файл должен содержать несколько строк, описывающих предназначение проекта или библиотеки (предполагая, что пользователь ничего не знает о проекте), URL основного исходного кода ПО и информацию об авторах. Если вы планируете читать код, то в первую очередь должны ознакомиться с этим файлом.

Файл INSTALL не особенно нужен в Python (но он может пригодиться для того, чтобы соответствовать требованиям лицензий вроде GPL). Инструкции по установке зачастую сокращаются до одной команды вроде pip install module или python setup.py install и добавляются в файл README.

Файл LICENSE должен присутствовать всегда и указывать лицензию, под которой ПО доступно общественности (см. раздел «Выбираем лицензию» далее в этой главе для получения более подробной информации.)

В файле TODO или одноименном разделе файла README должны быть представлены планы по развитию кода.

В файле CHANGELOG или одноименном разделе файла README должны быть приведены изменения, которые произошли с базой кода в последних версиях.

Публикация проекта

В зависимости от проекта ваша документация может содержать некоторые (или даже все) из этих компонентов:

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

• в разделе «Руководство» основные варианты использования описаны более подробно. Читатель пройдет пошаговую процедуру настройки рабочего прототипа;

• раздел API генерируется на основе кода (см. подраздел «Строки документации против блоковых комментариев» текущего раздела далее). В нем перечислены все доступные интерфейсы, параметры и возвращаемые значения;

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

Sphinx (http://sphinx.pocoo.org/) — самый популярный[49] инструмент для создания документации для Python. Используйте его: он преобразует язык разметки reStructured Text в огромное множество форматов, включая HTML, LaTeX (для печатаемых версий PDF), страницы руководства и простой текст.

Существует отличный бесплатный хостинг для вашей документации, созданной с помощью Sphinx: Read the Docs (http://readthedocs.org/). Используйте и его. Вы можете сконфигурировать его с помощью функций перехвата коммитов для вашего репозитория исходного кода, поэтому перестроение вашей документации будет происходить автоматически.

Sphinx использует формат reStructured Text (http://docutils.sourceforge.net/rst.html), с его помощью написана практически вся документация для Python. Если содержимое аргумента long_description функции setuptools.setup() написано в формате reStructured Text, оно будет отрисовано как HTML в PyPI — другие форматы будут представлены как простой текст. Он похож на Markdown, имеющий встроенные необязательные расширения. Следующие ресурсы подойдут для изучения синтаксиса:

• The reStructuredText Primer (http://sphinx.pocoo.org/rest.html);

• reStructuredText Quick Reference (http://bit.ly/restructured-text).

Или начните вносить свой вклад в документацию к любимому проекту и учитесь в процессе чтения.

Строки документации против блоковых комментариев

Строки документации и блоки комментариев не взаимозаменяемы. Оба варианта могут применяться для функции или класса. Рассмотрим пример использования обоих.

Первый блок комментария — это заметка для программиста.

Строки документации описывают, как работает функция или класс, она будет показана в интерактивной сессии Python, когда пользователь введет команду help(square_and_rooter).

Строки документации, размещенные в начале модуля или в начале файла __init__.py, также появятся в выводе функции help(). Функция autodoc для Sphinx может автоматически генерировать документацию с помощью правильно отформатированных строк. Инструкцию о том, как форматировать строки документации для autodoc, вы можете прочитать в руководстве к Sphinx (http://www.sphinx-doc.org/en/stable/tutorial.html#autodoc). Для получения более подробных сведений обратитесь к PEP 257 (https://www.python.org/dev/peps/pep-0257/).

Модуль журналирования был частью стандартной библиотеки Python, начиная с версии 2.3. Он кратко описан в PEP 282 (https://www.python.org/dev/peps/pep-0282/). Эту документацию сложно прочесть, исключение составляет простое руководство по журналированию (http://docs.python.org/howto/logging.html#logging-basic-tutorial).

Журналирование бывает двух видов:

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

• ведение контрольных журналов — записываются события для бизнес-анализа. Транзакции пользователя (вроде истории посещений) могут быть извлечены и объединены с другой информацией о нем (вроде итоговых покупок) для отчетности или оптимизации бизнес-целей.

Журналирование для библиотеки

Заметки о конфигурировании журналирования для библиотеки содержатся в руководстве по журналированию (http://bit.ly/configuring-logging). Еще один хороший ресурс с примерами использования журналирования — библиотеки, которые мы упомянем в следующей главе. Поскольку пользователь (а не библиотека) должен указывать, что случится, когда произойдет событие журналирования, мы должны констатировать:

Обработчик NullHandler делает то, что указано в его имени, то есть ничего. В противном случае пользователь должен будет самостоятельно отключать журналирование, если оно ему не требуется.

Правилом хорошего тона считается создание объектов средств ведения журнала только для использования вместе с переменной __name__ global: модуль журналирования создает иерархию средств ведения журнала с помощью точечной нотации, поэтому использование конструкции __name__ гарантирует отсутствие пересечений.

Рассмотрим пример применения этого приема в исходном коде библиотеки Requests (https://github.com/kennethreitz/requests) — разместите это в файле верхнего уровня __init__.py вашего проекта:

# Установить дескриптор журналирования по умолчанию для того, чтобы

# избежать появления предупреждений, которые гласят «Обработчик не найден».

import logging

try: # Python 2.7+

····from logging import NullHandler

except ImportError:

····class NullHandler(logging.Handler):

········def emit(self, record):

············pass

logging.getLogger(__name__). addHandler(NullHandler())

Журналирование для приложения

Twelve-Factor App (http://12factor.net/) (авторитетный источник, где перечислены правила хорошего тона, применяемые при разработке приложений) содержит раздел, в котором рассказывается о подобных правилах журналирования (http://12factor.net/logs). В нем предложено рассматривать события журнала как поток событий, для отправки этого потока в стандартный поток вывода нужно использовать среду приложения.

Существует минимум три способа конфигурирования средств ведения журнала (табл. 4.4).

Более подробная информация о формате INI содержится в разделе руководства журналирования, посвященном журналированию конфигурации (https://docs.python.org/howto/logging.html#configuring-logging). Минимальный файл конфигурации будет выглядеть так:

[loggers]

keys=root

[handlers]

keys=stream_handler

[formatters]

keys=formatter

[logger_root]

level=DEBUG

handlers=stream_handler

[handler_stream_handler]

class=StreamHandler

level=DEBUG

formatter=formatter

args=(sys.stderr,)

[formatter_formatter]

format=%(asctime)s %(name)-12s %(levelname)-8s %(message)s

asctime, name, levelname и message являются необязательными атрибутами библиотеки журналирования. Полный список доступных вариантов и их описание смотрите в документации Pytho (http://bit.ly/logrecord-attributes). Предположим, что наша конфигурация журналирования называется logging_conf.ini. Для того чтобы настроить средства ведения журнала с помощью этой конфигурации в коде, используем функцию logging.config.fileconfig():

import logging

from logging.config import fileConfig

fileConfig('logging_config.ini')

logger = logging.getLogger()

logger.debug('often makes a very good meal of %s', 'visiting tourists')

В версии Python 2.7 вы можете использовать словарь с деталями конфигурации. В PEP 391 (https://www.python.org/dev/peps/pep-0391) содержится список обязательных и необязательных элементов словаря конфигурации. Рассмотрим минимальную реализацию:

import logging

from logging.config dictConfig

·

logging_config = dict(

····version = 1,

····formatters = {

········'f': {'format':

············'%(asctime)s %(name)-12s %(levelname)-8s %(message)s' }

········},

····handlers = {

········'h': {'class': 'logging.StreamHandler',

············'formatter': 'f',

············'level': logging.DEBUG}

····loggers = {

········'root': {'handlers': ['h'],

············'level': logging.DEBUG}

········}

)

dictConfig(logging_config)

·

logger = debugging.getLogger()

logger.debug('often makes a very good meal of %s', 'visiting tourists')

Наконец, рассмотрим минимальную конфигурацию журналирования, расположенную непосредственно в коде:

import logging

logger = logging.getLogger()

handler = logging.StreamHandler()

formatter = logging.Formatter(

········'%(asctime)s %(name)-12s %(levelname)-8s %(message)s')

handler.setFormatter(formatter)

logger.addHandler(handler)

logger.setLevel(logging.DEBUG)

logger.debug('often makes a very good meal of %s', 'visiting tourists')

В Соединенных Штатах Америки, если для вашего исходного кода не указана лицензия, пользователи не получат законного права загружать, модифицировать или распространять его. Помимо этого, они не смогут вносить свой вклад в проект, если вы не укажете, по каким правилам играть. Поэтому вам нужна лицензия.

Лицензии

Если ваш проект основан на другом проекте, вам следует выбрать лицензию. Например, Python Software Foundation (PSF) просит всех, кто вносит свой вклад в исходный код, подписать соглашение для участников, которое формально лицензирует их код под одной из двух лицензий PSF[50] (при этом они сохраняют авторские права). Поскольку обе лицензии позволяют сублицензировать код с другими условиями, PSF может свободно распространять Python под своей лицензией Python Software Foundation License. Вы можете ознакомиться с часто задаваемыми вопросами о лицензии PSF (https://wiki.python.org/moin/PythonSoftwareFoundationLicenseFaq) (простым языком описывается, что пользователи могут и не могут делать). При этом дальнейшее применение дистрибутивов Python от PSF за пределами лицензии не предполагается.

Доступные варианты

Существует множество лицензий. PSF рекомендует использовать лицензию, одобренную Open Source Institute (OSI) (http://opensource.org/licenses). Если вы хотите вносить свой код в PSF, вам будет проще это делать, начав работу с одной из лицензий, указанных на странице https://www.python.org/psf/contrib/.

Лицензии для открытого исходного кода, как правило, делятся на две категории[51].

• Разрешительные. Часто называются похожими на Berkeley Software Distribution (BSD), больше концентрируются на том, чтобы дать пользователю свободу относительно того, что он хочет сделать со своим ПО.

Примеры:

○ лицензия Apache 2.0 (https://opensource.org/licenses/Apache-2.0) — это действующая лицензия, измененная таким образом, что пользователи могут включать ее, не изменяя проект, добавив ссылку на нее в каждый файл. Можно использовать код под лицензией Apache 2.0 с помощью GNU General Public License версии 3.0 (GPLv3);

○ лицензии BSD 2-clause (лицензия из двух пунктов) и BSD 3-clause (лицензия из трех пунктов) (https://opensource.org/licenses/BSD-3-Clause) — последняя представляет собой лицензию из двух пунктов, которая также содержит дополнительное ограничение использования торговых марок издателя;

○ лицензии Massachusetts Institute of Technology (MIT) (https://opensource.org/licenses/MIT) — версии Expat и X11 названы в честь популярных продуктов, использующих соответствующие лицензии;

○ лицензия Internet Software Consortium (ISC) (https://opensource.org/licenses/ISC) практически идентична лицензии MIT, за исключением нескольких строк, сейчас она считается устаревшей.

• Свободные. Больше концентрируются на том, чтобы гарантировать, что исходный код, включая изменения, которые в него вносятся, будет доступен. Среди таких лицензий наиболее известно семейство GPL. Текущая версия лицензии этого семейства — GPLv3 (https://opensource.org/licenses/GPL-3.0).

Лицензии, соответствующие критериям OSI, позволяют использовать код в коммерческих целях, модифицировать ПО и распространять его с разными ограничениями и требованиями. Все лицензии, перечисленные в табл. 4.5, ограничивают ответственность пользователя и требуют от него помнить об авторских правах и лицензии при любом распространении.

Лицензирование ресурсов

Книга Вана Линдберга (Van Lindberg) Intellectual Property and Open Source (издательство O’Reilly) — отличный ресурс, посвященный юридическим вопросам в отношении ПО с открытым исходным кодом. Эта книга поможет вам изучить лицензии и юридические тонкости, связанные с интеллектуальной собственностью (торговые марки, патенты, авторские права), а также их влияние на программы с открытым исходным кодом. Если вас не особо волнуют юридические моменты и вы хотите что-то быстро выбрать, вам могут помочь следующие сайты:

• GitHub предоставляет удобное руководство (http://choosealicense.com/), где сравниваются все лицензии в рамках нескольких предложений;

• на ресурсе TLDRLegal[52] (http://tldrlegal.com/) перечислено, что можно и чего нельзя делать под каждой лицензией;

• список лицензий, одобренных OSI (http://opensource.org/licenses), содержит полный текст всех лицензий, прошедших проверку на соответствие Open Source Definition (что позволит свободно использовать, модифицировать и распространять ПО).

Проект HowDoI, написанный Бенджамином Гляйтсманом (Benjamin Gleitzman), станет отличной стартовой точкой нашей одиссеи, несмотря на то что он состоит менее чем из 300 строк.

Читаем сценарий, состоящий из одного файла

Сценарий обычно имеет четко определенные точку входа, параметры и точку выхода. Благодаря этому читать его проще, чем библиотеки, которые предоставляют API или фреймворк.

Загрузите модуль HowDoI с GitHub[55]:

$ git clone https://github.com/gleitz/howdoi.git

$ virtualenv — p python3 venv # Или используйте mkvirtualenv, на ваш выбор…

$ source venv/bin/activate

(venv)$ cd howdoi/

(venv)$ pip install — editable.

(venv)$ python test_howdoi.py # Запустите юнит-тесты

Теперь у вас должен быть установлен исполняемый файл howdoi в каталоге venv/bin. (Вы можете увидеть его, введя cat 'which howdoi' в командной строке.) Он был сгенерирован автоматически, когда вы ввели команду pip install.

Документация к HowDoI находится в файле README.rst, который располагается в репозитории на GitHub (https://github.com/gleitz/howdoi). Это небольшое приложение для командной строки, позволяющее пользователям искать в Интернете ответы на вопросы, связанные с программированием.

В командной строке терминальной оболочки можно ввести команду howdoi — help, чтобы узнать, как пользоваться HowDoI:

(venv)$ howdoi — help

usage: howdoi [-h] [-p POS] [-a] [-l] [-c] [-n NUM_ANSWERS] [-C] [-v]

··············[QUERY [QUERY…]]

instant coding answers via the command line

positional arguments:

··QUERY ················the question to answer

optional arguments:

··-h, — help ···········show this help message and exit

··-p POS, — pos POS ····select answer in specified position (default: 1)

··-a, — all ············display the full text of the answer

··-l, — link ···········display only the answer link

··-c, — color ··········enable colorized output

··-n NUM_ANSWERS, — num-answers NUM_ANSWERS

························number of answers to return

··-C, — clear-cache ····clear the cache

··-v, — version ········displays the current version of howdoi

Из документации мы знаем, что HowDoI получает ответы на вопросы, связанные с программированием, из Интернета. В руководстве указано, что можно выбрать ответ в определенной позиции, раскрасить выводимую информацию, получить несколько ответов, а также то, что модуль имеет кэш, который можно очистить.

Мы можем подтвердить, что понимаем, как работает HowDoI. Рассмотрим пример:

(venv)$ howdoi — num-answers 2 python lambda function list comprehension

- Answer 1 —

[(lambda x: x*x)(x) for x in range(10)]

- Answer 2 —

[x() for x in [lambda m=m: m for m in [1,2,3]]]

# [1, 2, 3]

Мы установили HowDoI, прочли его документацию и теперь можем его использовать. Перейдем к чтению кода!

Если вы заглянете в каталог howdoi/, то увидите два файла: __init__.py, который состоит всего из одной строки, указывающей номер версии, и howdoi.py, который мы откроем и прочитаем.

Просматривая файл howdoi.py, мы увидим, что каждое новое определение функции использовано в следующей функции; это упрощает чтение кода. Каждая функция выполняет всего одну задачу (она вынесена в ее имя). Главная функция command_line_runner() располагается в нижней части файла howdoi.py.

Вместо того чтобы приводить здесь исходный код HowDoI, мы можем проиллюстрировать структуру его вызовов с помощью графа, показанного на рис. 5.1. Этот граф создан с помощью Python Call Graph (https://pycallgraph.readthedocs.io/), который предоставляет визуализацию функций, вызываемых при запуске сценария Python. Он хорошо работает с приложениями командной строки благодаря тому, что они имеют одну точку входа и относительно небольшое количество путей выполнения, по которым может пойти код. (Обратите внимание, что мы вручную удалили из отрисованного изображения функции, которые отсутствуют в проекте HowDoI, дабы вместить граф на страницу, а также немного переформатировали его.)

Код мог бы выглядеть как одна большая спагетти-функция, сложная для восприятия. Вместо этого код был намеренно разбит на отдельные функции, имеющие понятные имена. Кратко рассмотрим граф, изображенный на рис. 5.1: функция command_line_runner() анализирует входные данные и передает флаги и запрос, полученные от пользователя, в функцию howdoi(). Далее функция howdoi() оборачивает функцию _get_instructions() в блок try/except, чтобы можно было отловить ошибки соединения и вывести адекватное сообщение об ошибке (поскольку код приложения не должен завершать работу при наличии исключения).

Основную работу делает функция _get_instructions(): она вызывает функцию _get_links(), чтобы выполнить поиск ссылок, соответствующих запросу, в Google или на сайте Stack Overflow, а затем — функцию _get_answer() для каждого полученного результата (вплоть до предельного количества ссылок, указанного пользователем в командной строке, — по умолчанию одной).

Функция _get_answer() следует ссылке на ресурс Stack Overflow, извлекает код из ответа, раскрашивает его и возвращает функции _get_instructions(), которая объединяет все ответы в одну строку и возвращает их. Функции _get_links() и _get_answer() вызывают _get_result(), чтобы выполнить HTTP-запрос: _get_links() для запроса Google и _get_answer() для получения ссылок из запроса Google.

Функция _get_result() лишь оборачивает функцию requests.get() блоком try/except, чтобы можно было отловить ошибки SSL, вывести сообщение об ошибке и повторно сгенерировать исключение, дабы блок try/except верхнего уровня мог отловить его и выйти (это правило хорошего тона для любых программ).

Рис. 5.1. Прозрачные пути и прозрачные имена функций в графе вызовов проекта howdoi

Ключевое слово для перечисления сценариев консоли — console_scripts.

Объявляет, что исполняемый файл с именем howdoi в качестве цели будет иметь функцию howdoi.howdoi.command_line_runner(). Поэтому мы будем знать, что функция command_line_runner() является стартовой точкой для всего приложения.

Примеры из структуры HowDoI

HowDoI — это небольшая библиотека (в других разделах мы рассмотрим ее архитектуру более подробно, а здесь лишь скажем пару слов).

Мы не устанем повторять, насколько полезно разделять внутренние функции HowDoI таким образом, чтобы они делали лишь что-то одно. Существуют функции, чье единственное предназначение — оборачивание других функций в оператор try/except. (Единственная функция, имеющая оператор try/except, которая не следует этой практике, — _format_output(). Она задействует операторы try/except не для обработки исключений, а для определения языка программирования с целью подсветки синтаксиса.)

HowDoI проверяет и использует текущие системные значения, например с помощью функции urllib.request.getproxies() обрабатывается применение прокси-серверов (это подойдет для организаций вроде школ, которые имеют промежуточный сервер, фильтрующий соединение с Интернетом). Обратите внимание на этот сниппет:

XDG_CACHE_DIR = os.environ.get(

····'XDG_CACHE_HOME',

····os.path.join(os.path.expanduser('~'), '.cache')

)

Как вам узнать, что эти переменные существуют? Необходимость urllib.request.getproxies() обусловлена необязательными аргументами в requests.get(), поэтому часть этой информации доступна из сведений API о вызываемых вами библиотеках. Переменные среды зачастую нужны для определенной функциональности, поэтому, если библиотека предназначена для использования с конкретной базой данных или другим родственным приложением, в документации к этим приложениям будут перечислены актуальные переменные среды. Для систем POSIX хорошей стартовой точкой будет список стандартных переменных среды Ubuntu (https://help.ubuntu.com/community/EnvironmentVariables) или список переменных среды в спецификации POSIX (http://bit.ly/posix-env-variables), который указывает на другие важные списки.

Примеры из стиля HowDoI

HowDoI в основном следует PEP 8, но не в тех случаях, когда это вредит читаемости. Например, операторы импорта находятся в верхней части файла, но стандартная библиотека и внешние модули перемешаны. И несмотря на то что строковые константы в USER_AGENTS гораздо длиннее 80 символов, в строках нет места, где их можно было бы разбить естественным образом, поэтому они остаются целыми.

В нескольких следующих фрагментах кода показываются другие решения, связанные со стилем, о которых мы говорили в главе 4.

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

Остальные внутренние функции (_format_output(), _is_question(), _enable_cache() и _clear_cache()) не предназначены для использования за пределами пакета. Тестирующий сценарий howdoi/test_howdoi.py вызывает только функции без префиксов, проверяя, что средство форматирования работает, и передавая аргумент командной строки для раскрашивания в функцию верхнего уровня howdoi.howdoi() вместо того, чтобы передавать код в функцию howdoi._format_output().

Разница между версиями возможных зависимостей обрабатывается перед выполнением основного кода, поэтому пользователь знает, что проблем с зависимостями не возникнет, а проверка версий не засоряет код в других местах. Это хорошо, поскольку HowDoI поставляется как инструмент командной строки и дополнительные усилия, затрачиваемые пользователями, будут означать, что им не потребуется менять свою среду Python, чтобы установить инструмент. Рассмотрим фрагмент кода, в котором решается эта проблема:

try:

····from urllib.parse import quote as url_quote

except ImportError:

····from urllib import quote as url_quote

try:

····from urllib import getproxies

except ImportError:

····from urllib.request import getproxies

В следующем сниппете разница подходов к обработке Unicode в Python 2 и Python 3 нивелируется всего за семь строк путем создания функции u(x), которая либо эмулирует Python 3, либо не делает ничего. Кроме того, он следует новым принципам цитирования Stack Overflow (http://meta.stackexchange.com/questions/271080), приводя оригинальный исходный код:

# Разрешаем разницу обработки Unicode между Python 2 и 3

# http://stackoverflow.com/a/66 33040/3 05414

if sys.version < '3':

····import codecs

····def u(x):

········return codecs.unicode_escape_decode(x)[0]

else:

····def u(x):

········return x Питонские решения (красивое лучше, чем уродливое)

В следующем фрагменте кода из файла howdoi.py показываются продуманные, питонские решения. Функция get_link_at_pos() возвращает значение False, если результаты не найдены, или определяет ссылки на вопросы, касающиеся Stack Overflow, и возвращает ту из них, которая находится на желаемой позиции (либо последнюю, если ссылок недостаточно).

Функция _is_question() определяется в отдельной строке, что указывает четкое значение непонятному в противном случае поиску с использованием регулярных выражений.

Списковое включение читается как предложение благодаря отдельному определению функции _is_question() и информативным именам переменных.

Раннее использование оператора возврата упрощает код.

Дополнительный шаг, который тратится на присваивание значения переменной link, здесь…

…и здесь вместо использования двух отдельных операторов возврата, не имеющих именованных переменных, подчеркивает предназначение функции get_link_at_pos() с помощью прозрачных имен переменных. Код самозадокументирован.

Единый оператор возврата, находящийся на высшем уровне отступов, явно показывает, что все пути по коду завершатся либо сразу (поскольку ссылки не найдены), либо в конце функции, вернув ссылку. Работает наше правило: мы можем прочесть первую и последнюю строки этой функции и понять, что она делает. (Получив несколько ссылок и позицию, функция get_link_at_pos() возвращает одну ссылку, которая находится на заданной позиции.)

Diamond — это демон (приложение, постоянно работающее как фоновый процесс), который собирает метрики системы и публикует их в программах вроде MySQL, Graphite (http://graphite.readthedocs.org/) (платформа с открытым исходным кодом, созданная компанией Orbitz в 2008 году, которая сохраняет, получает и по возможности строит графики на основе временных рядов) и др. У нас есть возможность взглянуть на хорошую структуру пакетов, поскольку Diamond состоит из нескольких файлов и гораздо крупнее HowDoI.

Читаем более крупное приложение

Diamond также является приложением командной строки, поэтому, как и в случае с HowDoI, существуют четкая стартовая точка и четкие пути выполнения, однако теперь поддерживающий код находится в нескольких файлах.

Загрузите Diamond с GitHub (в документации говорится, что программа работает только в ОС CentOS или Ubuntu, но код, находящийся в ее файле setup.py, позволяет ей запускаться на всех платформах. Однако отдельные команды, которые стандартные сборщики используют для наблюдения за памятью, дисковым пространством и другими системными метриками, отсутствуют в Windows). На момент написания этой книги программа все еще использует Python 2.7:

$ git clone https://github.com/python-diamond/Diamond.git

$ virtualenv — p python2 venv # Она все еще несовместима с Python 3…

$ source venv/bin/activate

(venv)$ cd Diamond/

(venv)$ pip install — editable.

(venv)$ pip install mock docker-py # Эта зависимость нужна для тестирования.

(venv)$ pip install mock # Эта зависимость также нужна для тестирования.

(venv)$ python test.py # Запускаем юнит-тесты.

Как и в случае с библиотекой HowDoI, сценарий установки Diamond добавляет исполняемые файлы diamond и diamond-setup в каталог venv/bin/. В этот раз они не генерируются автоматически, а являются заранее написанными сценариями и лежат в каталоге Diamond/bin/. В документации говорится, что файл diamond запускает сервер, а diamond-setup — необязательный инструмент, который позволяет пользователям интерактивно изменять настройки сборщика в конфигурационном файле.

Существует множество дополнительных каталогов, пакет diamond находится внутри каталога Diamond/src. Мы взглянем на файлы из каталогов Diamond/src (в которых содержится основной код), Diamond/bin (хранится исполняемый файл diamond) и Diamond/conf (содержится пример конфигурационного файла). Остальные каталоги и файлы могут представлять интерес для тех, кто хочет распространять подобные приложения (в рамках этой книги мы их опустим).

Для начала можно попытаться понять идею проекта, взглянув на онлайн-документацию (http://diamond.readthedocs.io/). Цель Diamond — упрощение сборки системных метрик для кластеров машин. Появилась в 2011 году благодаря компании BrightCove, Inc., на сегодняшний день в ее базу кода внесли вклад более 200 человек.

После описания истории и предназначения в документации говорится, как установить и запустить демон: вам нужно лишь модифицировать предложенный файл конфигурации (у нас он находится по адресу conf/diamond.conf.example), поместить в стандартное место (/etc/diamond/diamond.conf) или по пути, который вы укажете в командной строке, — и вы готовы приступить к работе. Кроме того, на вики-странице проекта Diamond (https://github.com/BrightcoveOS/Diamond/wiki/Configuration) вы можете найти полезный раздел о конфигурации.

Из командной строки мы можем вывести на экран руководство по использованию с помощью команды diamond — help:

(venv)$ diamond — help

Usage: diamond [options]

Options:

··-h, — help ···········show this help message and exit

··-c CONFIGFILE, — configfile=CONFIGFILE

························config file

··-f, — foreground ·····run in foreground

··-l, — log-stdout ·····log to stdout

··-p PIDFILE, — pidfile=PIDFILE

························pid file

··-r COLLECTOR, — run=COLLECTOR

························run a given collector once and exit

··-v, — version ········display the version and exit

··-skip-pidfile ·······Skip creating PID file

··-u USER, — user=USER ·Change to specified unprivileged user

··-g GROUP, — group=GROUP

························Change to specified unprivileged group

··-skip-change-user ···Skip changing to an unprivileged user

··-skip-fork ··········Skip forking (damonizing) process

Из него мы узнаем, что демон использует файл конфигурации; по умолчанию работает в фоновом режиме; имеет возможность журналирования. Вы можете указать файл PID (process ID, «идентификатор процесса»), протестировать сборщики, можете изменить пользователя и группу процесса. По умолчанию он демонизирует (создаст копию) процесс[56].

Для того чтобы еще лучше понять Diamond, запустим его. Нам нужен модифицированный файл конфигурации, который мы можем поместить в созданный нами каталог Diamond/tmp. Находясь в нем, введите следующий код:

(venv)$ mkdir tmp

(venv)$ cp conf/diamond.conf.example tmp/diamond.conf

Далее отредактируйте файл tmp/diamond.conf, чтобы он выглядел так:

Из этого примера конфигурации видно следующее.

Существует несколько обработчиков, каждый из которых мы можем выбрать по имени класса.

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

Мы можем указать путь, который будет применен для поиска модулей сборщиков. Так Diamond узнает, где находятся пользовательские подклассы класса Collector (мы явно указываем это в файле конфигурации).

Конфигурацию обработчиков мы храним отдельно.

Далее запустите Diamond, указав, что журнал будет сохраняться по адресу /dev/stdout (будет использована стандартная конфигурация форматирования), что приложение не должно работать в фоновом режиме, что нужно опустить запись в файл PID и использовать новые файлы конфигурации:

(venv)$ diamond — l — f — skip-pidfile — configfile=tmp/diamond.conf

Для того чтобы завершить процесс, нажимайте Ctrl+C до тех пор, пока снова не появится командная строка. Журнал показывает, что делают сборщики и обработчики: сборщики собирают разные метрики (вроде объема общей, свободной памяти и памяти подкачки от MemoryCollector), которые обработчики форматируют и отправляют в разные точки назначения вроде Graphite, MySQL (в нашем тестовом случае — как сообщения журнала в /dev/stdout).

Для чтения более крупных проектов лучше использовать IDE — с их помощью вы можете быстро обнаружить оригинальное определение функций и классов исходного кода (при наличии определения можете найти все места в проекте, где задействованы функция или класс). Для использования этой функциональности укажите интерпретатору Python вашей IDE применять одну из виртуальных сред[57].

Вместо того чтобы разбирать каждую функцию, как мы сделали это для HowDoI, изучим рис. 5.2 (показаны операторы импорта). Схема демонстрирует, какие модули Diamond импортируют другие модули. Подобные рисунки помогают понять более крупные проекты. Можно начать с исполняемого файла diamond в левом верхнем углу и следовать всем операторам импорта в проекте Diamond. Помимо исполняемого файла diamond, в каждом квадрате указывается файл (модуль) или папка (пакет) в каталоге src/diamond.

Хорошо организованные и удачно названные модули Diamond позволяют понять идею кода, просто взглянув на схему: модуль diamond получает версию из util, затем настраивает журналирование с помощью utils.log и запускает экземпляр сервера с помощью server. Сервер импортирует почти все вспомогательные модули, используя классы utils.classes, чтобы получить доступ к обработчикам в handler и сборщикам, config — для чтения файла конфигурации и получения настроек для сборщиков (дополнительные пути для сборщиков, определенных пользователем), scheduler и signals — для установки интервала опроса для сборщиков, чтобы подсчитать их метрики, а также для настройки обработчиков и указания им приступать к обработке очереди метрик, которые нужно отправить.

Схема не включает в себя вспомогательные модули convertor.py и gmetric.py, используемые определенными сборщиками, а также более 20 реализаций обработчиков, определенных в подпакете handler, и более 100 реализаций сборщиков, определенных в каталоге проекта Diamond/src/collectors/ (которые находятся в другом месте, если процесс установки Diamond отличается от того, который мы выполнили при чтении, то есть использовали дистрибутивы пакетов PyPI или Linux вместо исходного кода). Они импортируются с помощью функции diamond.classes.load_dynamic_class(), которая затем вызывает функцию diamond.util.load_class_from_name() для загрузки классов на основе имен, представленных в строках конфигурационного файла, поэтому операторы импорта могут не вызывать их явно.

Рис. 5.2. Структура импортированных модулей в Diamond

Чтобы понять, для чего в проекте присутствуют пакет utils и модуль util, нужно открыть код: модуль util предоставляет функции, связанные с упаковкой Diamond (а не с его работой): функцию для получения номера версии на основе version.__VERSION__ и две функции, которые анализируют строки, позволяющие определить модули или классы и импортировать их.

····# Инициализация журналирования

····log = setup_logging(options.configfile, options.log_stdout)

##~~… Пропускаем все остальное…

def setup_logging(configfile, stdout=False):

····log = logging.getLogger('diamond')

····if stdout:

········log.setLevel(logging.DEBUG)

········streamHandler = logging.StreamHandler(sys.stdout)

········streamHandler.setFormatter(DebugFormatter())

········streamHandler.setLevel(logging.DEBUG)

········log.addHandler(streamHandler)

····else:

········##~~… Пропускаем это…

········logging.config.fileConfig(configfile,

························disable_existing_loggers=False)

### Настройки обработчиков

[handlers]

# обработчик(и) для журналирования

keys = rotated_file

Примеры из структуры Diamond

Diamond — это больше чем исполняемое приложение. Он также является библиотекой, которая предоставляет пользователям возможность создавать и применять собственные сборщики.

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

На схеме рис. 5.2 показан модуль сервера, взаимодействующий с тремя другими модулями проекта: diamond.handler, diamond.collector и diamond.utils.

В подпакете utils можно было бы разместить все классы и функции в одном большом модуле util.py, однако можно подключить пространства имен для того, чтобы разбить код на отдельные файлы, — и команда разработчиков ею воспользовалась. Отличный выбор!

Все реализации обработчиков содержатся в каталоге diamond/handler (это логично), но структура для сборщиков отличается. Для них не предусмотрен каталог — только модуль diamond/collector.py, в котором определяются базовые классы Collector и ProcessCollector. Все реализации подклассов класса Collector определены в каталоге Diamond/src/collectors/, в виртуальной среде они будут установлены по адресу venv/share/diamond/collectors, если вы устанавливали Diamond с помощью PyPI (рекомендованный способ), а не с помощью GitHub (как это сделали мы). Это помогает пользователю создать новые реализации сборщиков: размещение всех сборщиков в одном месте упрощает их поиск для приложения, а также создание аналогичных сборщиков. Наконец, каждая реализация сборщика в Diamond/src/collectors находится в своем каталоге (а не в отдельном файле), что позволяет разделить тесты для каждой реализации класса Collector. Также отлично придумано!

Добавить новую реализацию класса Collector нетрудно: нужно создать подкласс абстрактного базового класса diamond.collector.Collector[58], реализовать метод Collector.collect() и поместить реализацию в отдельный каталог по адресу venv/src/collectors/.

Сама по себе реализация сложна, но пользователь этого не знает. В данном разделе рассматриваются простая часть API сборщиков, которая видна пользователю, и сложный код, благодаря которому появился подобный интерфейс.

Сложное против запутанного. Мы можем сравнить работу со сложным кодом со швейцарскими часами — они просто работают, но внутри находится множество маленьких деталей, взаимодействующих с высокой точностью, чтобы упростить работу с API. Использование запутанного кода похоже на управление самолетом — вы наверняка должны знать, что делать, чтобы не разбиться и не сгореть[59]. Мы не хотим жить в мире без самолетов, но при этом желаем пользоваться часами, не вникая в тонкости их работы. Везде, где это возможно, создавайте менее сложные пользовательские интерфейсы.

Простой пользовательский интерфейс. Для того чтобы создать собственный сборщик данных, пользователь должен создать подкласс абстрактного класса Collector, а затем предоставить путь к нему с помощью конфигурационного файла. Рассмотрим пример нового определения класса Collector из класса Diamond/src/collectors/cpu/cpu.py. Когда Python ищет метод collect(), он сначала проверит на наличие CPUCollector, а затем, если оно не будет найдено, использует метод diamond.collector.Collector.collect(), что сгенерирует исключение NotImplementedError.

Код сборщика может выглядеть так:

# coding=utf-8

import diamond.collector

import psutil

class CPUCollector(diamond.collector.Collector):

····def collect(self):

········# В классе Collector содержится лишь инструкция raise(NotImplementedError)

········metric_name = "cpu.percent"

········metric_value = psutil.cpu_percent()

········self.publish(metric_name, metric_value)

Стандартное место для размещения определений сборщиков — каталог venv/share/diamond/collectors/, но вы можете хранить их по тому адресу, который укажете в свойстве collectors_path конфигурационного файла. Имя класса CPUCollector уже указано в примере конфигурационного файла. За исключением добавления спецификаций hostname или hostname_method в общие стандартные свойства (расположенные под конфигурационным файлом) или в отдельные переопределенные значения для сборщика, как показано в следующем примере, не нужно вносить другие изменения (в документации перечислены дополнительные настройки сборщиков (http://bit.ly/optional-collector-settings)):

[[CPUCollector]]

enabled = True

hostname_method = smart

Более сложен внутренний код. За кулисами сервер вызовет метод utils.load_collectors(), используя путь, указанный в collectors_path. Рассмотрим большую часть этой функции (мы сократили ее для удобства).

Разбиваем строку (первый вызов функции); в противном случае пути являются списками строк, содержащих пути, которые указывают места, где реализованы пользовательские подклассы класса Collector.

Здесь мы рекурсивно проходим по заданным путям, добавляя каждую папку в sys.path, чтобы далее можно было импортировать подклассы класса Collector.

Здесь выполняется рекурсия — метод load_collectors() вызывает сам себя[60].

После загрузки сборщиков из подкаталогов обновите оригинальный словарь пользовательских сборщиков, добавив туда загруженные сборщики из этих подкаталогов.

С момента введения Python 3.1 модуль importlib стандартной библиотеки Python является предпочтительным способом сделать это (с помощью модуля importlib.import_module; фрагменты importlib.import_module также были портированы в Python 2.7). Это показывает, как можно программно импортировать модуль, используя строку с его именем.

Так можно программно получить доступ к атрибутам модуля, имея лишь строку с именем атрибута.

Метод load_dynamic_class здесь можно и не использовать. Он повторно импортирует модуль, проверяет, что названный класс является классом на самом деле, проверяет, что он является подклассом класса Collector, и, если это верно, — возвращает только что загруженный класс. Избыточность часто встречается в исходном коде, который пишут большие группы людей.

Здесь они получают имя класса для дальнейшего использования при применении настроек из файла конфигурации (имея только строку, содержащую имя класса).

Примеры из стиля Diamond

В Diamond вы можете найти отличный пример использования замыкания, который демонстрирует все, о чем мы говорили в пункте «Замыкания с поздним связыванием» подраздела «Распространенные подводные камни» раздела «Стиль кода» главы 4 по поводу того, что такое поведение зачастую весьма желательно.

Пример использования замыкания (когда подводный камень вовсе не подводный камень). Замыкание — это функция, использующая переменные, доступные в локальной области видимости, которые в противном случае будут недоступны при вызове функции. В других языках их, возможно, будет трудно реализовать и понять, но это не относится к Python, поскольку в нем функции обрабатываются так же, как и любые другие объекты[61]. Например, функции могут быть переданы как аргумент, также их можно возвращать из других функций.

Рассмотрим фрагмент кода исполняемого файла diamond, который показывает, как реализовать замыкание в Python.

Когда мы пропускаем код, отсутствующие части описываем в комментарии, перед которым стоят две тильды (##~~).

Мы пользуемся файлом PID[62], чтобы убедиться, что демон уникален (то есть мы не запустили его дважды случайно), а также для быстрого сообщения с другими сценариями при передаче им связанных идентификаторов процессов. Этот файл также нужен для того, чтобы удостовериться, что процесс завершился ненормально (поскольку в этом сценарии файл PID удаляется лишь при нормальном завершении работы).

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

sigint_handler() и есть замыкание. Оно определяется внутри функции main(), а не на высшем уровне, за пределами других функций, поскольку ему нужно знать, искать ли файл PID, и если да — то где.

Позволяет получить информацию из параметров командной строки, которую нельзя получить до вызова функции main(). Это означает, что все параметры, связанные с файлом PID, являются локальными переменными пространства имен функции main.

Замыкание (функция sigint_handler()) отправляется обработчику сигналов; будет использовано для обработки сигналов SIGINT и SIGTERM.

Tablib — это библиотека Python, которая преобразует данные в различные форматы, сохраняет их в объекте класса Dataset, а несколько объектов типа Datasets — в объекте класса Databook. Объекты класса Dataset хранятся в форматах JSON, YAML, DBF и CSV (файлы в этих форматах можно импортировать), наборы данных могут быть экспортированы в форматах XLSX, XLS, ODS, JSON, YAML, DBF, CSV, TSV и HTML. Библиотека Tablib выпущена Кеннетом Ритцем (Kenneth Reitz) в 2010 году, имеет интуитивный дизайн API, характерный для всех проектов Ритца.

Читаем небольшую библиотеку

Tablib — это библиотека, а не приложение, поэтому не имеет четко определенной точки входа, как в случае с HowDoI и Diamond.

Загрузите Tablib из GitHub:

$ git clone https://github.com/kennethreitz/tablib.git

$ virtualenv — p python3 venv

$ source venv/bin/activate

(venv)$ cd tablib

(venv)$ pip install — editable.

(venv)$ python test_tablib.py # Run the unit tests.

Документация Tablib (http://docs.python-tablib.org/) начинается с упоминания варианта использования, затем в ней более подробно описываются возможности библиотеки: она предоставляет объект типа Dataset, который имеет строки, столбцы и заголовки. Вы можете выполнять операции ввода/вывода из разных форматов для объекта типа Dataset. В разделе, содержащем более сложные варианты использования, говорится, что вы можете добавлять к строкам теги и создавать унаследованные столбцы, которые являются функциями других столбцов.

Tablib — это библиотека, а не исполняемый файл, как в случае с HowDoI или Diamond, поэтому вы можете открыть интерактивную сессию Python и использовать функцию help() для исследования API. Рассмотрим пример применения класса tablib.Dataset, разных форматов данных и способа работы I/O:

>>> import tablib

>>> data = tablib.Dataset()

>>> names = ('Black Knight', 'Killer Rabbit')

>>>

>>> for name in names:

… ····fname, lname = name.split()

… ····data.append((fname, lname))

…

>>> data.dict

[['Black', 'Knight'], ['Killer', 'Rabbit']]

>>>

>>> print(data.csv)

Black,Knight

Killer,Rabbit

>>> data.headers=('First name', 'Last name')

>>> print(data.yaml)

- {First name: Black, Last name: Knight}

- {First name: Killer, Last name: Rabbit}

>>> with open('tmp.csv', 'w') as outfile:

… ····outfile.write(data.csv)

…

64

>>> newdata = tablib.Dataset()

>>> newdata.csv = open('tmp.csv'). read()

>>> print(newdata.yaml)

- {First name: Black, Last name: Knight}

- {First name: Killer, Last name: Rabbit}

Структура файлов, находящихся в каталоге tablib/, выглядит так:

tablib

|- __init__.py

|- compat.py

|- core.py

|- formats/

|- packages/

Каталоги tablib/formats/ и tablib/packages/ рассматриваются в следующих разделах.

Python поддерживает строки документации на уровне модулей, как и строки документации, которые мы уже описали, — строковые литералы, являющиеся первым выражением в функции, классе или методе. На сайте Stack Overflow приведены полезные советы о том, как задокументировать модули (http://stackoverflow.com/a/2557196). Для нас это означает, что существует еще один способ исследовать исходный код — мы можем ввести команду head *.py в терминальной оболочке, находясь на верхнем уровне пакета, чтобы показать все строки документации модуля. Вот что мы увидим для библиотеки Tablib:

Мы узнали следующее.

API высшего уровня (содержимое файла __init__.py доступно в каталоге tablib после выполнения оператора import tablib) имеет всего девять точек входа: классы Databook и Dataset упоминаются в документации, detect может использоваться для определения форматирования, import_set и import_book должны импортировать данные, а последние три класса — InvalidDatasetType, InvalidDimensions и UnsupportedFormat — выглядят как исключения (если код следует принципам PEP 8, мы можем сказать, какие объекты являются пользовательскими классами на основе их регистра).

tablib/compat.py — это модуль совместимости. Беглый взгляд на него покажет, что он обрабатывает проблемы совместимости между Python 2 и Python 3 аналогично HowDoI, разрешая разные местоположения и имена к одинаковым символам, которые будут использованы в tablib/core.py.

В файле tablib/core.py в соответствии с его именем реализуются объекты Tablib вроде Dataset и Databook.

(venv)$ pip install sphinx

(venv)$ cd docs

(venv)$ make html

(venv)$ open _build/html/index.html # Для просмотра результата.

(venv)$ python — c 'import sphinx.themes;print(sphinx.themes.__path__)'

.. autoclass:: Dataset

····:inherited-members:

Примеры из структуры Tablib

Главная особенность, которую мы хотим подчеркнуть в Tablib, — отсутствие использования классов в модулях в tablib/formats/ (это идеально иллюстрирует наше утверждение, что не нужно везде применять классы). Далее мы приведем фрагменты кода, демонстрирующие использование синтаксиса декоратора в Tablib, а также задействуем класс property (https://docs.python.org/library/functions.html#property) для создания унаследованных атрибутов вроде ширины и высоты набора данных. Помимо этого, покажем, как динамически он регистрирует форматы файлов, чтобы избежать дупликации шаблонного кода для разных типов формата (CSV, YAML и т. д.).

В последних двух подразделах мы рассмотрим, как Tablib использует зависимости, полученные от третьей стороны, а затем обсудим свойство __slots__ объектов нового класса. Вы можете пропустить эти разделы и при этом продолжать жить счастливой питонской жизнью.

Каталог форматов содержит все определенные для ввода/вывода форматы файлов. Имена модулей _csv.py, _tsv.py, _json.py, _yaml.py, _xls.py, _xlsx.py, _ods.py и _xls.py начинаются с нижнего подчеркивания — это указывает пользователю библиотеки, что свойства не предназначены для непосредственного использования. Мы можем перейти в каталог formats и выполнять поиск классов и функций. Команда grep ^class formats/*.py показывает отсутствие определений классов, а команда grep ^def formats/*.py — что каждый модуль содержит одну или несколько следующих функций:

• detect(stream) определяет формат файла, основываясь на содержимом потока;

• dset_sheet(dataset, ws) форматирует клетки для таблиц Excel;

• export_set(dataset) экспортирует набор данных в заданный формат, возвращая отформатированную строку в новом формате (для Excel возвращает объект bytes или бинарную строку в Python 2);

• import_set(dset, in_stream, headers=True) заменяет содержимое набора данных содержимым входного потока;

• export_book(databook) экспортирует объекты Datasheet в Databook в заданном формате, возвращая объект типа string или bytes;

• import_book(dbook, in_stream, headers=True) заменяет содержимое databook содержимым входного потока.

Это примеры применения модулей как пространств имен (в конце концов, они же являются отличной штукой) для разделения функций вместо того, чтобы использовать ненужные классы. Мы узнаем предназначение каждой функции по ее имени, например formats._csv.import_set(), formats._tsv.import_set() и formats._json.import_set() импортируют наборы данных из файлов в формате CSV, TSV и JSON соответственно. Другие функции отвечают за экспорт данных и определение формата файла (где это возможно) для каждого доступного Tablib формата.

Tablib — наша первая библиотека, в которой используется синтаксис декораторов Python, описанный в подразделе «Декораторы» раздела «Структурируем проект» главы 4. Синтаксисом предусмотрено указывать символ @ перед именем функции, вся конструкция размещается над другой функцией. Декоратор изменяет (или декорирует) функцию, которая находится под ним. В следующем фрагменте кода свойство изменяет функции Dataset.height и Dataset.width, делая их дескрипторами — классами, в которых определен хотя бы один из следующих методов: __get__(), __set__() или __delete__() (геттер, сеттер и метод удаления). Например, поиск атрибута Dataset.height приведет к срабатыванию функции-геттера, сеттера или удаления в зависимости от контекста применения атрибута. Такое поведение присуще только новым классам (их мы вскоре обсудим). Для получения более подробной информации о дескрипторах обратитесь к довольно полезному руководству по Python по адресу https://docs.python.org/3/howto/descriptor.html.

Именно так используется декоратор. В данном случае свойство изменяет Dataset.height, чтобы оно вело себя как свойство, а не как связанный метод. Он может работать только с методами классов.

Когда свойство применяется как декоратор, атрибут height вернет высоту Dataset, но вы не можете задать высоту множества данных, вызвав Dataset.height.

Так выглядят атрибуты height и width при использовании:

>>> import tablib

>>> data = tablib.Dataset()

>>> data.header = ("amount", "ingredient")

>>> data.append(("2 cubes", "Arcturan Mega-gin"))

>>> data.width

2

>>> data.height

1

>>>

>>> data.height = 3

Traceback (most recent call last):

····File "", line 1, in 

AttributeError: can't set attribute

Доступ к data.height можно получить так же, как и к любому другому атрибуту, но изменить его значение вы не можете — оно высчитывается на основе данных и всегда актуально. Такой дизайн API весьма эргономичен: конструкцию data.height проще ввести на клавиатуре, чем data.get_height(); понятно, что означает data.height. Поскольку значение этого свойства выводится на основе данных (значение свойства нельзя задать, для него определена только функция-геттер), можно не переживать, что значение свойства рассинхронизируется с реальными данными.

Декоратор свойства можно применить только к атрибутам классов и только к тем классам, которые наследуют от base object object (например, class MyClass(object), а не class MyClass() — в Python 3 всегда выполняется наследование от объекта).

Один и тот же инструмент используется при создании API для импорта и экспорта данных в Tablib для разных форматов (Tablib не хранит строку для каждого формата). Вместо этого применяются Dataset-атрибуты csv, json и yaml, они похожи на свойства Dataset.height и Dataset.width, показанные в предыдущем примере: вызывают функцию, которая генерирует результат из сохраненных данных или преобразует входной формат и затем заменяет основные данные. Но существует только один набор данных.

Когда свойство data.csv находится с левой стороны знака «равно», вызывается функция-сеттер для этого свойства, которая преобразует dataset из формата CSV. Когда свойство data.yaml находится с правой стороны знака «равно» или стоит отдельно, вызывается функция-геттер для создания строки в заданном формате на основе внутреннего набора данных. Рассмотрим пример.

Свойство data.csv, которое стоит с левой стороны от знака «равно» (оператора присваивания), вызывает функцию formats.csv.import_set(), передавая data в качестве первого аргумента, и строку, содержащую ингредиенты Пангалактического Грызлодера, в качестве второго аргумента.

Свойство data.yaml, стоящее отдельно, вызывает функцию formats.yaml.export_set(), передавая data в качестве аргумента, выводя строку в формате YAML для функции print().

Функции для получения, установки и удаления данных могут быть привязаны к единому атрибуту с помощью property. Его сигнатура выглядит так: property(fget=None, fset=None, fdel=None, doc=None), fget определяет функцию-геттер (formats.csv.import_set()), fset — функцию-сеттер (formats.csv.export_set()), а fdel — функцию удаления данных (оставлена пустой). Далее мы увидим код, в котором программно устанавливаются свойства форматирования.

Tablib помещает все подпрограммы для форматирования в подпакет formats. Это делает чище основной модуль core.py — и целый пакет становится модульным; добавлять новые форматы файлов будет нетрудно. Несмотря на то что можно копировать фрагменты практически идентичного кода и импортировать поведение при импорте и экспорте для каждого формата отдельно, все форматы программно загружаются в свойства, названные в честь каждого формата, в класс Dataset.

В следующем примере кода мы выводим все содержимое файла formats/__init__.py, поскольку файл не так велик и мы хотим показать, как определяется formats.available.

В этой строке интерпретатору Python явно указывается, что файл имеет кодировку UTF-8[63].

Определение formats.available находится в файле formats/__init__.py. Его также можно получить с помощью функции dir(tablib.formats), но приведенный выше список более прост для восприятия.

В файле core.py вместо примерно 20 (безобразных и сложных для поддержки) повторяющихся описаний функции для каждого формата код импортирует каждый формат программно, вызывая функцию self._register_formats() в конце метода __init__() класса Dataset. Рассмотрим фрагмент кода, в котором приводится метод Dataset._register_formats().

Символ @classmethod является декоратором (они подробно описаны в подразделе «Декораторы» подраздела «Структурируем проект» главы 4). Декоратор модифицирует метод _register_formats() таким образом, что он начинает передавать в качестве первого аргумента класс объекта (Dataset), а не его экземпляр (self).

Параметр formats.available определен в файле formats/__init__.py и содержит все доступные форматы.

В этой строке setattr присваивает значение атрибуту с именем fmt.title (то есть Dataset.csv или Dataset.xls). Это значение особенное: функция property(fmt.export_set, fmt.import_set) превращает Dataset.csv в свойство.

Если свойство fmt.import_set не будет определено, возникнет исключение AttributeError.

Если функции импорта нет, попробуйте присвоить лишь поведение экспорта.

Если нет ни функции импорта, ни функции экспорта, не присваивайте ничего.

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

\t и \n — управляющие последовательности, которые представляют собой, соответственно, символ табуляции и новую строку. Все они перечислены в документации к строковым литералам Python (https://docs.python.org/3/reference/lexical_analysis.html#index-18).

Зависимости Tablib в данный момент поставляются с кодом — в каталоге packages, но могут в будущем быть перемещены в систему надстроек. Каталог packages содержит сторонние пакеты, используемые внутри Tablib, чтобы гарантировать совместимость; другой вариант — указание версий в файле setup.py, который будет загружен и установлен в момент установки Tablib. Этот прием рассматривается в разделе «Зависимости, получаемые от третьей стороны» раздела «Структурируем проект» главы 4. Для Tablib был выбран вариант поведения, позволяющий снизить количество зависимостей, который нужно загружать пользователям, и поскольку иногда для Python 2 и Python 3 требуются разные пакеты, в этом случае включаются оба пакета. (Соответствующий пакет импортируется, функции вызываются с помощью их обычного имени в файле tablib/compat.py.) Таким образом, Tablib может иметь одну базу кода вместо двух — по одной для каждой версии Python. Раз каждая из зависимостей имеет собственную лицензию, на верхний уровень каталога проекта был добавлен документ NOTICE, в котором перечисляются лицензии каждой зависимости.

Скорости Python предпочитает читаемость. Его дизайн, афоризмы, из которых состоит его дзен, и раннее влияние, которое на него оказали языки вроде ABC (http://bit.ly/abc-to-python), — все это заставляет ставить дружелюбие к пользователю над производительностью (более подробно об оптимизации мы поговорим в разделе «Скорость» главы 8).

Использование свойства __slots__ в Tablib — этот тот случай, когда оптимизация имеет значение. Данная ссылка выглядит несколько странно, она доступна только для новых классов (они описаны через несколько страниц), но мы хотим показать, что при необходимости вы можете оптимизировать Python.

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

Рассмотрим фрагмент из документации __slots__ (http://bit.ly/__slots__-doc).

Обычно вам не следует об этом беспокоиться: обратите внимание, что свойство __slots__ не появляется в классах Dataset или Databook — только в классе Row, но поскольку рядов данных может быть очень много, использование __slots__ выглядит хорошим решением. Класс Row не показан в tablib/__init__.py, поскольку является вспомогательным классом для класса Dataset, для каждой строки создается один объект такого класса.

Рассмотрим, как выглядит определение __slots__ в самом начале определения класса Row:

class Row(object):

····"""Внутренний объект Row. Используется в основном для фильтрации."""

····__slots__ = ['_row', 'tags']

····def __init__(self, row=list(), tags=list()):

········self._row = list(row)

········self.tags = list(tags)

····#

····#… и т. д…

····#

Проблема в том, что больше не существует атрибута __dict__, в котором хранятся объекты класса Row, но функция pickle.dump() (вызывается для сериализации объектов) по умолчанию использует __dict__ для сериализации объектов, если только не определен метод __getstate__(). Аналогично во время десериализации (процесса, который читает сериализованные байты и восстанавливает объект в памяти), если метод __setstate__() не определен, метод pickle.load() загружает данные в атрибут объекта __dict__. Рассмотрим, как это обойти.

class Row(object):

····#

····#… пропускаем другие определения…

····#

····def __getstate__(self):

········slots = dict()

········for slot in self.__slots__:

············attribute = getattr(self, slot)

············slots[slot] = attribute

········return slots

····def __setstate__(self, state):

········for (k, v) in list(state.items()):

············setattr(self, k, v)

Для получения более подробной информации о методах __getstate__() и __setstate__() и сериализации обратитесь к документации __getstate__ (http://bit.ly/__getstate__-doc).

Примеры из стиля Tablib

Мы подготовили лишь один пример использования стиля в Tablib — перегрузка операторов (это позволяет рассмотреть детали модели данных Python). Настройка поведения ваших классов позволит разработчикам, использующим ваш API, писать хороший код.

Перегрузка операторов (красивое лучше, чем уродливое). В этом фрагменте кода приводится перегрузка операторов Python, чтобы выполнять операции для строк или столбцов набора данных. В первом фрагменте кода показывается интерактивное применение квадратных скобок [] как для численных индексов, так и для имен столбцов, а во втором — код, который использует это поведение.

Если вы указываете в квадратных скобках числа, этот оператор вернет строку, которая находится в заданной позиции.

Благодаря этому оператору присваивания с квадратными скобками…

… вместо исходной одной оливки у вас становится две.

Здесь выполняется удаление с помощью вырезки — 2:7 указывает на числа 2, 3, 4, 5, 6, но не 7.

Взгляните, насколько сокращается рецепт после выполнения.

Вы также можете получить доступ к столбцам с помощью имени.

В части кода класса Dataset, которая определяет поведение оператора «квадратные скобки», показывается, как обрабатывать доступ по имени столбца и номеру строки.

Во-первых, проверим, что именно мы ищем — столбец (True, если key является строкой) или строку (True, если key является числом или вырезкой).

Этот код проверяет наличие ключа в self.headers и затем…

…явно вызывает исключение KeyError, поэтому, если вы получаете доступ по имени столбца, поведение будет таким же, как и у словаря. Весь блок if/else необязателен для работы функции — если его опустить, исключение ValueError будет сгенерировано функцией self.headers.index(key) в том случае, если ключа нет в self.headers. Единственным его предназначением является предоставление пользователю библиотеки более информативной ошибки.

Здесь определяется, чем является ключ — числом или вырезкой (вроде 2:7). Если вырезкой, _results будет списком, а не объектом класса Row.

Здесь обрабатывается вырезка. Поскольку строки возвращаются как кортежи, значения представляют собой неизменяемые копии реальных данных — и данные из набора (которые хранятся в списках) не будут случайно повреждены в результате присваивания.

Метод __setitem__() может изменить одну строку, но не столбец. Это сделано намеренно, так как не существует способа изменить содержимое всего столбца; с точки зрения целостности данных такое решение не самый плохой выбор. Пользователь всегда может преобразовать столбец и внедрить его в любую позицию с помощью одного из методов insert_col(), lpush_col() или rpush_col().

Метод __delitem__() удалит столбец или строку, используя ту же логику, что и метод __getitem__().

Для получения более подробной информации о перегрузке операторов и других особых методах смотрите документацию Python о специальных именах методов (http://bit.ly/special-method-names).

В День святого Валентина в 2011 году Кеннет Ритц (Kenneth Reitz) опубликовал «любовное письмо», адресованное сообществу Python, — библиотеку Requests. Она была воспринята с большим энтузиазмом благодаря интуитивно понятному дизайну API (это значит, что API настолько прост и понятен, что вам почти не нужна документация для того, чтобы им пользоваться).

Читаем более крупную библиотеку

Библиотека Requests намного крупнее библиотеки Tablib и имеет множество модулей. Однако мы подходим к вопросу ее прочтения точно так же — просмотрим документацию и будем следовать API в коде.

Загрузите Requests из GitHub:

$ git clone https://github.com/kennethreitz/requests.git

$ virtualenv — p python3 venv

$ source venv/bin/activate

(venv)$ cd requests

(venv)$ pip install — editable.

(venv)$ pip install — r requirements.txt # Required for unit tests

(venv)$ py.test tests # Run the unit tests.

Некоторые тесты могут дать сбой. Например, если ваш интернет-провайдер перехватывает ошибку 404 для того, чтобы показать вам какую-нибудь рекламу, вы не сможете сгенерировать исключение ConnectionError.

Библиотека Requests находится в гораздо более крупном пакете, поэтому сначала просмотрите лишь заголовки разделов в документации к Requests (http://docs.python-requests.org/). Requests расширяет библиотеки urrlib и httplib, которые вы можете найти в стандартной библиотеке Python, предоставляя методы, выполняющие запросы HTTP. Библиотека предусматривает поддержку международных доменов и URL, автоматическую декомпрессию, автоматическое декодирование содержимого, проверку сертификатов SSL, поддержку прокси для HTTP(S) и другую функциональность, определенную стандартами Internet Engineering Task Force (IETF) для HTTP с помощью запросов комментария (requests for comment, RFC) 7230–7235[64].

Библиотека Requests стремится покрыть все спецификации HTTP от IETF, задействуя всего несколько функций, набор аргументов с ключевым словом и несколько классов.

Как и в случае Tablib, в строках документации содержится достаточно информации для того, чтобы использовать Requests, не обращаясь к документации, размещенной онлайн. Рассмотрим следующий пример:

>>> import requests

>>> help(requests) # Показывает руководство по использованию

···················# и указывает искать 'requests.api'

>>> help(requests.api) # Показывает подробное описание API

>>>

>>> result = requests.get('https://pypi.python.org/pypi/requests/json')

>>> result.status_code

200

>>> result.ok

True

>>> result.text[:42]

'{\n····"info": {\n········"maintainer": null'

>>>

>>> result.json(). keys()

dict_keys(['info', 'releases', 'urls'])

>>>

>>> result.json()['info']['summary']

'Python HTTP for Humans.'

Рассмотрим содержимое пакета Requests.

cacert.pem — стандартный набор сертификатов, который используется при проверке сертификатов SSL.

Requests имеет простую структуру, за исключением каталога packages, хранящего сторонние зависимости chardet и urllib3. Они импортируются как requests.packages.chardet и requests.packages.urllib3, поэтому программисты все еще могут получить доступ к chardet и urllib3 из стандартной библиотеки.

Мы можем разобраться в происходящем благодаря удачно выбранным именам модулей, но если нужно больше информации, просмотрите строки документации модуля, введя head *.py в каталоге верхнего уровня. В следующем списке эти строки документации приводятся в сокращенном виде (не показывается compat.py). Исходя из его имени (он назван так же, как и аналогичный файл библиотеки Reitz’s Tablib, мы можем сделать вывод, что он отвечает за совместимость между Python 2 и Python 3).

• api.py — реализует Requests API.

• hooks.py — предоставляет возможность использовать систему функций перехвата Requests.

• models.py — содержит основные объекты, которыми пользуется Requests.

• sessions.py — предоставляет объект Session для управления настройками и их сохранения между запросами (cookies, авторизация, прокси).

• auth.py — содержит дескрипторы для аутентификации в Requests.

• status_codes.py — таблица, в которой соотносятся заголовки состояний и их коды.

• cookies.py — код для совместимости, который позволяет использовать cookielib.CookieJar с запросами.

• adapters.py — содержит транспортные адаптеры, которые Requests применяет для определения и поддержания соединений.

• exceptions.py — все исключения Requests.

• structures.py — структуры данных, которыми пользуется Requests.

• certs.py — возвращает предпочтительный набор сертификатов CA по умолчанию, в котором перечислены доверенные сертификаты SSL.

• utils.py — предоставляет вспомогательные функции, которые используются внутри Requests и могут применяться внешними пользователями.

Что мы узнали из заголовков:

• существует система функций перехвата (hooks.py) — это подразумевает, что пользователь может модифицировать способ работы библиотеки Requests. Мы не будем обсуждать этот вопрос подробно, чтобы не отвлекаться от темы;

• основным модулем является models.py, поскольку в нем содержатся «основные объекты, которыми пользуется Requests»;

• основная причина существования sessions.Session — сохранение cookies между несколькими запросами (например, это может понадобиться во время аутентификации);

• соединение HTTP создается с помощью объектов из модуля adapters.py;

• остальная часть проекта довольно очевидна: auth.py нужен для аутентификации, status_codes.py содержит коды состояний, cookies.py нужен для добавления и удаления cookies, exceptions.py — для исключений, structures.py содержит структуры данных (например, не зависящий от регистра словарь), utils.py — вспомогательные функции.

Идея поместить модуль коммуникации в отдельный файл adapters.py инновационна (во всяком случае для этого разработчика). Это означает, что models.Request, models.PreparedRequest и models.Response на самом деле ничего не делают — просто сохраняют данные, возможно несколько изменяя их в угоду представлению, сериализации или кодировке. Действия обрабатываются отдельными классами, которые существуют только для того, чтобы выполнить, например, аутентификацию или коммуникацию. Каждый класс делает что-то одно, и каждый модуль содержит классы, выполняющие похожие задачи, — в этом и проявляется питонский подход, который многие из нас используют для определений функций.

def delete(url, **kwargs):

····"""Отправляет запрос DELETE.

····:param url: URL для нового объекта: class:'Request'.

····:param \*\*kwargs: Необязательные аргументы, которые принимает

·······················''request''.

····:return: объект класса: class:'Response '

····:rtype: requests.Response

····"""

····return request('delete', url, **kwargs)

Примеры из структуры Requests

Все любят API Requests — его просто запомнить, он помогает пользователям писать простой и красивый код. В этом разделе сначала рассматривается предпочтительный дизайн для более полных сообщений об ошибках и запоминающийся API, который, как мы думаем, привел к созданию модуля requests.api. Затем мы рассмотрим разницу между объектами requests.Request и urllib.request.Request и расскажем, для чего существует объект requests.Request.

Функции, определенные в файле api.py (за исключением request()), названы в честь методов запросов HTTP[65]. Все методы запроса практически одинаковы, за исключением имени метода и возможных параметров с ключевыми словами, поэтому мы удалим из этого фрагмента весь код, расположенный в файле requests/api.py после функции get().

Функция request() содержит в своей сигнатуре **kwargs. Это означает, что дополнительные аргументы с ключевым словом не сгенерируют исключение, также это скрывает параметры от пользователя.

В документации, опущенной в этом фрагменте для краткости, описывается каждый аргумент с ключевым словом, с которым связано действие. Использование **kwargs из сигнатуры вашей функции — единственный способ для пользователя сказать, каким должно быть содержимое **kwargs, не заглядывая в код.

С помощью оператора with Python поддерживает контекст времени выполнения. Оно может быть использовано для любого объекта, для которого определены методы __enter__() и __exit__(). Метод __enter()__ будет вызван при входе в оператор with, а __exit__() — при выходе, независимо от того, завершился оператор нормально или сгенерировал исключение.

Функция get() получает ключевое слово params=None, применяя значение по умолчанию None. Аргумент с ключевым словом params важен для get, поскольку будет использоваться в строке запроса HTTP. Предоставление отдельных аргументов с ключевым словом дает гибкость действий опытным пользователям (благодаря оставшимся **kwargs), упрощая работу для 99 % людей, которым это не нужно.

По умолчанию функция request() не разрешает перенаправление, поэтому на этом шаге устанавливается значение True, если пользователь не сделал этого заранее.

Функция get() вызывает функцию request(), передавая в качестве первого параметра get. Создание функции get имеет два преимущества перед использованием строкового аргумента вроде request("get"…). Во-первых, даже без документации становится очевидно, какие методы HTTP доступны в этом API. Во-вторых, если пользователь сделает опечатку в имени метода, исключение NameError будет сгенерировано быстрее, и, возможно, его будет проще отследить, чем если бы оно было сгенерировано более глубоко в коде.

В файле requests/api.py нет новой функциональности; она существует для того, чтобы предоставить пользователю простой API. Плюс размещение строковых методов HTTP непосредственно в API в качестве имен функций означает, что любая опечатка в имени метода будет найдена на ранних этапах, например:

>>> requests.foo('http://www.python.org')

Traceback (most recent call last):

····File "", line 1, in 

AttributeError: 'module' object has no attribute 'foo'

>>>

>>> requests.request('foo', 'http://www.python.org')

Файл __init__.py предоставляет классы Request, PreparedRequest и Response из файла models.py как часть основного API. Зачем вообще нужен файл models.Request? В стандартной библиотеке уже существует urllib.requests.Request, и в файле cookies.py находится объект MockRequest, который оборачивает models.Request, чтобы он работал как urllib.requests.Request для http.cookiejar[66]. Это означает, что любые методы, необходимые для взаимодействия объекта типа Request с библиотекой cookies, намеренно исключены из requests.Request. Для чего эти лишние усилия?

Дополнительные методы в MockRequest (нужен для эмуляции urllib.request.Request для библиотеки cookies) используются библиотекой cookies для управления cookies. За исключением функции get_type() (которая обычно возвращает http или https при использовании) и непроверяемого свойства (в нашем случае True), они связаны с URL или заголовками запросов.

Связанные с заголовками:

• add_unredirected_header() — добавить в заголовок новую пару ключ-значение;

• get_header() — получить определенное имя из словаря заголовков;

• get_new_headers() — получить словарь, содержащий новые заголовки (которые добавлены с помощью cookielib);

• has_header() — проверяем, существует ли имя в словаре заголовков.

Связанные с URL:

• get_full_url() — соответствует своему имени;

• host и origin_req_host — свойства, чьи значения устанавливаются путем вызова методов get_host() и get_origin_req_host() соответственно;

• get_host() — извлекает хост из URL (например, www.python.org из https://www.python.org/dev/peps/pep-0008/);

• get_origin_req_host() — вызывает get_host()[67].

Все они являются функциями доступа, за исключением MockRequest.add_unredirected_header().

В строке документации к объекту MockRequest указывается, что «оригинальный объект запроса доступен только для чтения».

В requests.Request вместо этого непосредственно доступны атрибуты данных. Это делает все функции доступа ненужными: для получения или установки заголовков требуется лишь получить доступ к словарю request-instance.headers. Аналогично пользователь может получить или изменить строку URL: request-instance.url.

Объект PreparedRequest инициализируется пустым и заполняется при вызове метода prepared-request-instance.prepare(), что наполняет его релевантными данными (обычно получаемыми путем вызова объекта Request). В этот момент применяются исправления регистра символов, кодировки и пр. Содержимое объекта после подготовки можно будет отправить на сервер, но к каждому атрибуту все еще можно получить доступ непосредственно. Доступен даже PreparedRequest._cookies, однако нижнее подчеркивание, с которого начинается это имя, намекает на то, что атрибут не предназначен для использования за пределами класса, не запрещая при этом доступ (мы все — ответственные пользователи).

Этот выбор позволяет пользователю изменять объекты, но они становятся гораздо читабельнее, а дополнительная работа, выполняемая внутри PreparedRequest, позволяет исправить проблемы с регистром и использовать словарь вместо CookieJar (ищите оператор if isinstance()/else):

#

#… из файла models.py…

#

class PreparedRequest():

····#

····#…пропускаем все остальное…

····#

····def prepare_cookies(self, cookies):

········"""Подготавливает данные заданного HTTP cookie.

········Эта функция в итоге генерирует заголовок ''Cookie'' на основе

········предоставленных cookies с использованием cookielib. Из-за особенностей

········дизайна cookielib заголовок не будет сгенерирован повторно,

········если он уже существует. Это значит, что эта функция может быть

········вызвана всего один раз во время жизни объекта

········:class:'PreparedRequest '. Любые последующие вызовы

········''prepare_cookies'' не возымеют эффекта, если только заголовок "Cookie"

········не будет удален заранее."""

········if isinstance(cookies, cookielib.CookieJar):

············self._cookies = cookies

········else:

············self._cookies = cookiejar_from_dict(cookies)

········cookie_header = get_cookie_header(self._cookies, self)

········if cookie_header is not None:

············self.headers['Cookie'] = cookie_header

Эти детали могут показаться незначительными, но они позволяют создать интуитивно понятный API.

Примеры из стиля Requests

Примеры стиля из Requests демонстрируют использование множеств (по нашему мнению, о них незаслуженно забывают!), мы также взглянем на модуль requests.status_codes module — он задействуется для упрощения стиля остального кода и позволяет избежать применения жестко закодированных кодов состояния HTTP в остальных местах.

Мы еще не приводили пример использования множеств в Python. Множества в Python ведут себя так же, как и множества в математике: вы можете выполнить операции вычитания, объединения (с помощью оператора ИЛИ) и пересечения (с помощью оператора И):

>>> s1 = set((7,6))

>>> s2 = set((8,7))

>>> s1

{6, 7}

>>> s2

{8, 7}

>>> s1 — s2 # разность множеств

{6}

>>> s1 | s2 # объединение множеств

{8, 6, 7}

>>> s1 & s2 # пересечение множеств

{7}

Рассмотрим пример работы с множествами, вы можете найти его в конце этой функции из файла cookies.py (рядом с пометкой ):

Спецификация **kwargs позволяет пользователю предоставить любой параметр с ключевым словом для cookie (или не предоставлять их вовсе).

Арифметика множеств! Питонская. Простая. Доступная в стандартной библиотеке. Для словаря функция set() формирует множество ключей.

Это отличный пример того, что разбиение длинной строки на две короткие более разумно. Дополнительная переменная err не нанесла никакого вреда.

Вызов result.update(kwargs) обновляет словарь result парами ключ/значение, содержащимися в словаре kwargs, заменяя существующие пары или создавая те пары, которых не было.

Здесь вызов метода bool() возвращает значение True, если объект верен (это значит, что его значение оценивается как True — в данном случае вызов bool(result['port']) оценивается как True, если значение не равно None и не является пустым контейнером).

Сигнатура для инициализации cookielib.Cookie представляет собой набор из 18 позиционных аргументов и одного аргумента с ключевым словом (rfc2109 по умолчанию считается равным False). Нам, как среднестатистическим пользователям, невозможно запомнить все значения и их позиции, поэтому Requests позволяет присваивать значения позиционным аргументам, основываясь на их имени, как в случае аргументов с ключевым словом, отправляя целый словарь.

Файл status_codes.py нужен только для того, чтобы создать объект, который может искать коды состояний по атрибуту. Мы сначала покажем определение словаря в файле status_codes.py, а затем — фрагмент кода файла sessions.py, в котором словарь используется.

Все эти варианты состояния OK станут ключами словаря. За исключением счастливого человека (\\o/) и флажка ().

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

LookupDict позволяет получать доступ к своим элементам через точку, как это показано в следующей строке.

codes.ok == 200 и codes.okay == 200.

А также codes.OK == 200 и codes.OKAY == 200.

Вся эта работа нужна для того, чтобы создать словарь с кодами состояний. Для чего? Использование словаря вместо цифр на протяжении всего кода (что чревато опечатками) позволяет повысить читаемость, а также хранить все эти числа в одном файле. Поскольку все числа, представляющие коды, записаны в словарь, каждое из них появится всего один раз. Вероятность опечаток при этом значительно снижается.

Преобразование ключей в атрибуты вместо их использования в качестве строк в словаре также снижает риск опечаток. Рассмотрим пример кода из файла sessions.py, который гораздо легче прочитать, когда в нем используются слова, а не числа.

Здесь импортируются коды состояний.

Классы-примеси мы опишем в пункте «Примеси (еще одна отличная штука)» подраздела «Примеры структуры из Werkzeug» следующего раздела. Примесь предоставляет методы перенаправления для основного класса Session, который определен в том же файле, но не показан в приведенном фрагменте.

Мы входим в цикл, который следует за перенаправлениями и позволяет нам получить желаемое содержимое. Вся логика цикла удалена из этого фрагмента для краткости.

Коды состояний, представленные в виде текста, гораздо читабельнее, нежели числа (которые трудно запомнить): codes.see_other в противном случае выглядел бы как 303.

codes.found выглядел бы как 302, а codes.moved — как 301. Поэтому код становится самозадокументированным; мы можем узнать значение переменных из их имен. Мы избежали засорения кода опечатками, добавив точечную нотацию вместо словаря и строк (например, codes.found вместо codes["found"]).

Для того чтобы прочесть код Werkzeug, нам нужно узнать, как веб-серверы общаются с приложениями. В следующих абзацах мы попытались представить максимально короткий обзор по этому вопросу.

Интерфейс Python для взаимодействия серверов с веб-приложениями определен в PEP 333, который написан Филипом Джей Эби (Phillip J. Eby) в 2003 году[68]. В нем указано, как веб-сервер (вроде Apache) общается с приложением Python или фреймворком.

1. Сервер будет вызывать приложение каждый раз при получении запроса HTTP (например, GET или POST).

2. Это приложение вернет итерабельный объект, содержащий объекты типа bytestrings, который сервер использует для ответа на запрос HTTP.

3. В спецификации также говорится, что приложение примет два параметра, например webapp(environ, start_response). Параметр environ будет содержать данные, связанные с запросом, а параметр start_response будет функцией или другим вызываемым объектом, который задействуется для отправки обратно заголовка (например, ('Content-type', 'text/plain')) и состояния (например, 200 OK) на сервер.

В этом документе есть еще полдюжины страниц дополнительной информации. В середине PEP 333 вы можете увидеть впечатляющее заявление о том, как новый стандарт сделал возможным создание веб-фреймворков.

Четыре года спустя, в 2007 году, Армин Ронакер (Armin Ronacher) выпустил Werkzeug, намереваясь создать библиотеку WSGI, которую можно использовать для создания приложений WSGI и компонентов промежуточного ПО.

Werkzeug — самый крупный пакет из тех, что мы рассмотрим, поэтому перечислим только несколько его проектных решений.

Читаем код инструментария

Инструментарий (тулкит) — это набор совместимых утилит. В случае Werkzeug все они связаны с приложениями WSGI. Хороший способ понять отдельные утилиты и их предназначение — взглянуть на юнит-тесты, именно так мы и поступим.

Получаем Werkzeug из GitHub:

$ git clone https://github.com/pallets/werkzeug.git

$ virtualenv — p python3 venv

$ source venv/bin/activate

(venv)$ cd werkzeug

(venv)$ pip install — editable.

(venv)$ py.test tests # Запускаем юнит-тесты

В документации Werkzeug (http://werkzeug.pocoo.org/) перечислены основные возможности, предоставляемые библиотекой, — реализация спецификации WSGI 1.0 (PEP 333, https://www.python.org/dev/peps/pep-0333/), система маршрутизации URL, возможность анализировать и сохранять заголовки HTTP, объекты, которые предоставляют запросы и ответы HTTP, сессии и поддержка cookie, загрузка файлов и другие утилиты и надстройки от сообщества. Плюс полноценный отладчик.

Эти руководства информативны, но мы используем документацию к API вместо того, чтобы изучать компоненты библиотеки. В следующем разделе рассматриваются обертки для Werkzeug (http://werkzeug.pocoo.org/docs/0.11/wrappers/) и документация по маршрутизации (http://werkzeug.pocoo.org/docs/0.11/routing/).

Werkzeug предоставляет вспомогательные программы для приложений WSGI, поэтому, чтобы узнать, что предоставляет Werkzeug, мы можем начать с приложения WSGI, а затем использовать несколько вспомогательных программ от Werkzeug. Это первое приложение несколько отличается от того, что предоставлено в PEP 333, и не использует Werkzeug. Второе приложение делает то же самое, что и первое, но при этом использует Werkzeug:

def wsgi_app(environ, start_response):

····headers = [('Content-type', 'text/plain'), ('charset', 'utf-8')]

····start_response('200 OK', headers)

····yield 'Hello world.'

# Это приложение делает то же самое, что и указанное выше:

response_app = werkzeug.Response('Hello world!')

Werkzeug реализует класс werkzeug.Client, который ведет себя как реальный веб-сервер при выполнении подобных проверок. Ответ клиента будет иметь тип аргумента response_wrapper. В этом коде мы создаем клиентов и используем их для вызова приложений WSGI, которые создали ранее. Для начала разберем простое приложение WSGI (его ответ будет размещен в объекте werkzeug.Response):

>>> import werkzeug

>>> client = werkzeug.Client(wsgi_app, response_wrapper=werkzeug.Response)

>>> resp=client.get("?answer=42")

>>> type(resp)

>>> resp.status

'200 OK'

>>> resp.content_type

'text/plain'

>>> print(resp.data.decode())

Hello world.

Далее используйте объект werkzeug.Response:

>>> client = werkzeug.Client(response_app, response_wrapper=werkzeug.Response)

>>> resp=client.get("?answer=42")

>>> print(resp.data.decode())

Hello world!

Класс werkzeug.Request предоставляет содержимое словаря среды (аргумент environ, расположенный над wsgi_app()) в форме, удобной для пользователя, а также декоратор для преобразования функции, которая принимает объект werkzeug.Request и возвращает werkzeug.Response приложению WSGI:

>>> @werkzeug.Request.application

… def wsgi_app_using_request(request):

… ····msg = "A WSGI app with: \n method: {}\n path: {}\n query: {}\n"

… ····return werkzeug.Response(

… ········msg.format(request.method, request.path, request.query_string))

…

Она возвращает следующий код:

>>> client = werkzeug.Client(

… ····wsgi_app_using_request, response_wrapper=werkzeug.Response)

>>> resp=client.get("?answer=42")

>>> print(resp.data.decode())

A WSGI app with:

···method: GET

···path: /

···query: b'answer=42'

Теперь мы знаем, как работать с объектами werkzeug.Request и werkzeug.Response. Помимо них, в документации указана маршрутизация. Рассмотрим фрагмент кода, где она используется; порядковые номера определяют шаблон и соответствующее ему значение.

Объект werkzeug.Routing.Map предоставляет основные функции для маршрутизации. Правила соответствия применяются по порядку; первым идет выбранное правило.

Если в строке-заполнителе для правила нет условий в угловых скобках, принимается только полное совпадение, вторым результатом работы метода urls.match() является пустой словарь:

>>> env = werkzeug.create_environ(path='/')

>>> urls = url_map.bind_to_environ(env)

>>> urls.match()

('index', {})

В противном случае второй записью является словарь, в котором соотнесены именованные термы с соответствующими значениями, например person соотнесен с Galahad:

>>> env = werkzeug.create_environ(path='/Galahad?favorite+color')

>>> urls = url_map.bind_to_environ(env)

>>> urls.match()

('ask', {'person': 'Galahad'})

Обратите внимание, что Galahad мог соответствовать маршруту other, но вместо этого ему соответствует Lancelot, поскольку выбирается первое соответствующее правило:

>>> env = werkzeug.create_environ(path='/Lancelot')

>>> urls = url_map.bind_to_environ(env)

>>> urls.match()

('other', {'other': 'Lancelot'})

Если в списке правил соответствие не найдено, генерируется исключение:

>>> env = werkzeug.test.create_environ(path='/shouldnt/match')

>>> urls = url_map.bind_to_environ(env)

>>> urls.match()

Traceback (most recent call last):

File "", line 1, in 

File "[…path…]/werkzeug/werkzeug/routing.py", line 1569, in match

raise NotFound()

werkzeug.exceptions.NotFound: 404: Not Found

Вы соотнесли маршрут запроса с соответствующей конечной точкой. В следующем фрагменте кода продолжим рассматривать суть предыдущего примера:

@werkzeug.Request.application

def send_to_endpoint(request):

····urls = url_map.bind_to_environ(request)

····try:

········endpoint, kwargs = urls.match()

········if endpoint == 'index':

············response = werkzeug.Response("You got the index.")

········elif endpoint == 'ask':

············questions = dict(

················Galahad='What is your favorite color?',

················Robin='What is the capital of Assyria?',

················Arthur='What is the air-speed velocity

························of an unladen swallow?')

············response = werkzeug.Response(questions[kwargs['person']])

········else:

············response = werkzeug.Response("Other: {other}".format(**kwargs))

····except (KeyboardInterrupt, SystemExit):

········raise

····except:

········response = werkzeug.Response(

········'You may not have gone where you intended to go,\n'

········'but I think you have ended up where you needed to be.',

········status=404

········)

····return response

Для того чтобы протестировать этот фрагмент, снова используйте класс werkzeug.Client:

>>> client = werkzeug.Client(send_to_endpoint, response_wrapper=werkzeug.Response)

>>> print(client.get("/"). data.decode())

You got the index.

>>>

>>> print(client.get("Arthur"). data.decode())

What is the air-speed velocity of an unladen swallow?

>>>

>>> print(client.get("42"). data.decode())

Other: 42

>>>

>>> print(client.get("time/lunchtime"). data.decode()) # no match

You may not have gone where you intended to go,

but I think you have ended up where you needed to be.

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

Поскольку мы уже знаем, как работают маршрутизация и обертки для запроса и ответа, то теперь можем прочесть файлы werkzeug/test_routing.py и werkzeug/test_wrappers.py.

Когда мы в первый раз откроем файл werkzeug/test_routing.py, можем быстро взглянуть на связи между модулями, поискав импортированные объекты во всем файле.

Рассмотрим все операторы импорта.

Конечно, pytest используется для тестирования.

Модуль uuid применяется всего в одной функции test_uuid_converter(), чтобы подтвердить, что работает преобразование между объектами типа string и uuid.UUID (строка Universal Unique Identifier (универсальный уникальный идентификатор) позволяет уникально идентифицировать объекты в Интернете).

Функция strict_eq() используется довольно часто и определена в файле werkzeug/tests/__init__.py. Предназначена для тестирования и нужна только потому, что в Python 2 существовало явное преобразование между строками в формате Unicode и byte, но на это нельзя полагаться в Python 3.

werkzeug.routing — это тестируемый модуль.

Объект Response применяется всего в одной функции test_dispatch() для подтверждения, что werkzeug.routing.MapAdapter.dispatch() передает правильную информацию, отправленную приложению WSGI.

Эти объекты словаря используются по одному разу. ImmutableDict нужен для того, чтобы подтвердить, что неизменяемый каталог, указанный в werkzeug.routing.Map, действительно неизменяем, а MultiDict — чтобы предоставить несколько значений с ключами строителю URL и подтвердить, что был собран правильный URL.

Функция create_environ() предназначена для тестирования: создает среду WSGI без реального запроса HTTP.

Цель этого анализа — исследование связей между модулями. Мы обнаружили, что werkzeug.routing лишь импортирует некоторые специальные структуры данных. Остальная часть юнит-тестов показывает область действия модуля маршрутизации. Например, вы можете использовать символы, не входящие в ASCII:

def test_environ_nonascii_pathinfo():

····environ = create_environ(u'/лошадь')

····m = r.Map([

········r.Rule(u'/', endpoint='index'),

········r.Rule(u'/лошадь', endpoint='horse')

····])

····a = m.bind_to_environ(environ)

····strict_eq(a.match(u'/'), ('index', {}))

····strict_eq(a.match(u'/лошадь'), ('horse', {}))

····pytest.raises(r.NotFound, a.match, u'/барсук')

Существуют тесты для сборки и анализа URL и даже утилиты для поиска ближайшего совпадения, которое не является полным. Вы можете выполнить пользовательскую обработку в процессе преобразования типов путей и строк URL:

def test_converter_with_tuples():

····'''

····Регрессионные тесты для https://github.com/pallets/werkzeug/issues/709

····'''

····class TwoValueConverter(r.BaseConverter):

········def __init__(self, *args, **kwargs):

············super(TwoValueConverter, self).__init__(*args, **kwargs)

············self.regex = r'(\w\w+)/(\w\w+)'

········def to_python(self, two_values):

············one, two = two_values.split('/')

············return one, two

········def to_url(self, values):

············return "%s/%s" % (values[0], values[1])

····map = r.Map([

········r.Rule('//', endpoint='handler')

····], converters={'two': TwoValueConverter})

····a = map.bind('example.org', '/')

····route, kwargs = a.match('/qwert/yuiop/')

····assert kwargs['foo'] == ('qwert', 'yuiop')

Аналогично немногое импортируется в файле werkzeug/test_wrappers.py. В тесте показывается функциональность, доступная объекту Request, — cookies, кодировки, аутентификация, безопасность, таймауты кэша и даже мультиязычные кодировки:

def test_modified_url_encoding():

····class ModifiedRequest(wrappers.Request):

········url_charset = 'euc-kr'

····req = ModifiedRequest.from_values(u'/?foo= '.encode('euc-kr'))

····strict_eq(req.args['foo'], u' ')

Как правило, чтение тестов позволяет более подробно ознакомиться с возможностями библиотеки. Теперь понятно, для чего нужна библиотека Werkzeug, поэтому можно двигаться дальше.

[tox]

envlist = py{26,27,py,33,34,35}-normal, py{26,27,33,34,35}-uwsgi

·

[testenv]

passenv = LANG

deps=

# General

····pyopenssl

····greenlet

····pytest

····pytest-xprocess

····redis

····requests

····watchdog

····uwsgi: uwsgi

·

# Python 2

····py26: python-memcached

····py27: python-memcached

····pypy: python-memcached

·

# Python 3

····py33: python3-memcached

····py34: python3-memcached

····py35: python3-memcached

·

whitelist_externals=

····redis-server

····memcached

····uwsgi

commands=

····normal: py.test []

····uwsgi: uwsgi

···········-pyrun {envbindir}/py.test

···········-pyargv — kUWSGI — cache2=name=werkzeugtest,items=20 — master

Примеры стиля из Werkzeug

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

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

Поиск в словарях с помощью ключей в Python использует соотнесение хэшей, как и поиск в множестве. Python не имеет операторов switch case. (Их отклонили как непопулярные в PEP 3103 (https://www.python.org/dev/peps/pep-3103/).) Вместо этого пользователи Python используют инструкцию if/elif/else или (как показано здесь) питонское решение — поиск в словаре.

Обратите внимание, что в первый раз попытка преобразования выполняется к более ограниченному типу int, перед тем как попытаться выполнить преобразование к типу float.

Питонским решением также является использование оператора try/except для infer type.

Эта часть необходима, поскольку код находится в файле werkzeug/routing.py, а анализируемая строка является частью URL. Здесь проверяется наличие кавычек, при обнаружении они удаляются.

text_type преобразовывает строки в формат Unicode таким образом, что они остаются совместимыми и с Python 2, и с Python 3. Этот код практически аналогичен функции u(), показанной в разделе «HowDoI» в начале главы 5.

Если вы используете в своем коде длинные регулярные выражения, не забывайте про параметр re.VERBOSE[69] — сделайте их более понятными для других людей. Пример регулярных выражений показан во фрагменте файла werkzeug/routing.py:

import re

····_rule_re = re.compile(r'''

····(?P[^<]*) # static rule data

····<

····(?:

········(?P[a-zA-Z_][a-zA-Z0-9_]*) # имя преобразователя

········(?:\((?P.*?)\))? # аргументы преобразователя

········\: # разделитель переменных

····)?

····(?P[a-zA-Z_][a-zA-Z0-9_]*) # имя переменной

····>

''', re.VERBOSE)

Примеры структуры из Werkzeug

В первых двух примерах, связанных со структурой, демонстрируются питонские способы использования динамической типизации. Мы предупреждали, что присваивание переменной разных значений может приводить к появлению проблем (см. подраздел «Динамическая типизация» раздела «Структурируем проект» главы 4), но не упомянули преимущества такого присваивания. Одно из них заключается в том, что вы можете использовать любой тип объекта, который ведет себя предсказуемо. Это называется утиной типизацией. Утиная типизация исповедует следующую философию: «Если что-то выглядит, как утка[70], крякает, как утка, то это и есть утка».

В обоих примерах используется возможность вызвать объекты, которые не являются функциями: вызов cached_property.__init__() позволяет проинициализировать экземпляры класса, чтобы их можно быть применять как обычные функции, а вызов Response.__call__() позволяет объекту класса Response вызвать как функцию самого себя.

В последнем фрагменте используется реализация некоторых классов-примесей (каждый из них определяет какую-либо функциональность в объекте класса Request), характерная для Werkzeug, чтобы продемонстрировать, что такие классы — это тоже отличная штука.

Werkzeug применяет утиную типизацию для того, чтобы создать декоратор @cached_property. Когда мы говорили о свойстве, описывая проект Tablib, то упоминали, что оно похоже на функцию. Обычно декораторы являются функциями, но поскольку тип ничем не навязывается, они могут быть любым вызываемым объектом: свойство на самом деле является классом. (Вы можете сказать, что оно задумывалось как функция, поскольку его имя не начинается с прописной буквы, а в PEP 8 говорится, что имена классов должны начинаться c прописной буквы.) При использовании нотации, похожей на вызов функции (property()), будет вызван метод property.__init__() для инициализации и возврата экземпляра свойства — класс, для которого соответствующим образом определен метод __init__(), работает как вызываемая функция. Кря.

В следующем фрагменте кода содержится полное определение свойства cached_property, которое является подклассом класса property. Документация класса cached_property говорит сама за себя. Когда это свойство будет использоваться для декорирования BaseRequest.form в коде, который мы только что видели, instance.form будет иметь тип cached_property и с точки зрения пользователя будет вести себя как словарь, поскольку для него определены методы __get__() и __set__(). При получении доступа к BaseRequest.form в первый раз он считает данные формы (если она существует), а затем запишет их в instance.form.__dict__, чтобы к ним можно было получить доступ в дальнейшем:

class cached_property(property):

····"""Декоратор, который преобразует функцию в ленивое свойство.

········Обернутая функция в первый раз вызывается для получения результата,

········затем полученный результат используется при следующем обращении к value::

············class Foo(object):

················@cached_property

················def foo(self):

····················# выполняем какие-нибудь важные расчеты

····················return 42

········Класс должен иметь '__dict__' для того, чтобы это свойство работало.

········"""

········# деталь реализации: для подкласса, встроенного

········# в Python свойства-декоратора

········# мы переопределяем метод __get__ так, чтобы получать кэшированное

········# значение.

········# Если пользователь хочет вызвать метод __get__ вручную, свойство будет

········# работать как обычно, поскольку логика поиска реплицируется

········# в методе __get__ при вызове вручную.

········def __init__(self, func, name=None, doc=None):

············self.__name__ = name or func.__name__

············self.__module__ = func.__module__

············self.__doc__ = doc or func.__doc__

············self.func = func

········def __set__(self, obj, value):

············obj.__dict__[self.__name__] = value

········def __get__(self, obj, type=None):

············if obj is None:

················return self

············value = obj.__dict__.get(self.__name__, _missing)

············if value is _missing:

················value = self.func(obj)

················obj.__dict__[self.__name__] = value

············return value

Взглянем на этот код в действии:

>>> from werkzeug.utils import cached_property

>>>

>>> class Foo(object):

… ····@cached_property

… ····def foo(self):

… ········print("You have just called Foo.foo()!")

… ········return 42

…

>>> bar = Foo()

>>>

>>> bar.foo

You have just called Foo.foo()!

42

>>> bar.foo

42

>>> bar.foo # Обратите внимание, сообщение не выводится снова…

42

Класс Response собран с помощью функциональности класса BaseResponse, как и Request. Мы изучим его интерфейс и не будем смотреть на сам код. Взглянем лишь на строку документации для класса BaseResponse, чтобы узнать, как его использовать.

В примере, показанном в строках документации, функция index() вызывается в ответ на запрос HTTP. Ответом будет строка Index page.

Эта сигнатура нужна в приложениях WSGI, как указано в PEP 333/PEP 3333.

Класс Response является подклассом BaseResponse, поэтому ответ представляет собой объект класса BaseResponse.

Для ответа 404 требуется лишь установить значение ключевого слова status.

И вуаля — объект response является вызываемой функцией сам по себе, все сопутствующие заголовки и детали имеют разумные значения по умолчанию (либо переопределены, если путь отличается от /).

Как объект класса может быть вызываемой функцией? Дело в том, что для него был определен метод BaseRequest.__call__. В следующем примере кода мы покажем лишь этот метод.

Эта сигнатура позволяет сделать объекты класса BaseResponse вызываемыми функциями.

Здесь учтены требования к вызову приложений WSGI для функции start_response.

А здесь возвращается итерабельный объект типа bytes.

Пора извлечь следующий урок: если язык позволяет что-то сделать, почему бы не сделать это? После того как мы поняли, что можно добавить метод __call__() к любому объекту и сделать его вызываемой функцией, мы можем вернуться к оригинальной документации и еще раз перечитать раздел о модели данных в Python (http://docs.python.org/3/reference/datamodel.html).

Примеси в Python — это классы, которые предназначены для того, чтобы добавлять определенную функциональность — набор связанных атрибутов. В Python, в отличие от Java, вы можете реализовать множественное наследование. Это означает, что парадигма, при которой создаются подклассы для полдюжины разных классов одновременно, — это один из способов разбить функциональность на отдельные классы. Это похоже на пространства имен.

Подобное разбиение может быть полезно во вспомогательной библиотеке вроде Werkzeug, поскольку она говорит пользователю, какие функции связаны друг с другом, а какие — нет. Разработчик может быть уверен, что атрибуты в одном классе-примеси не будут изменены функциями другого класса-примеси.

В Werkzeug методы класса-примеси иногда могут требовать наличия определенных атрибутов. Эти требования зачастую приводятся в строке документации класса-примеси.

В классе UserAgentMixin нет ничего особенного; он создает подкласс объекта, что выполняется по умолчанию в Python 3 и настоятельно рекомендуется для совместимости с Python 2. Все это нужно делать явно, поскольку «явное лучше, чем неявное».

UserAgentMixin.user_agent предполагает, что существует атрибут self.environ.

При включении в список базовых классов для Request предоставляемый им атрибут становится доступным с помощью вызова Request(environ). user_agent.

Больше ничего нет — мы полностью рассмотрели определение класса Request. Вся функциональность предоставляется базовым классом или классами-примесями. Модульными, подключаемыми и такими же великолепными, как Форд Префект.

>>> class A(object):

… ····"""Новый класс, он является подклассом object."""

…

>>> class B:

… ····"""Старый класс."""

…

>>> dir(A)

['__class__', '__delattr__', '__dict__', '__doc__', '__format__',

'__getattribute__', '__hash__', '__init__', '__module__', '__new__',

'__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__sizeof__',

'__str__', '__subclasshook__', '__weakref__']

>>>

>>> dir(B)

['__doc__', '__module__']

>>>

>>> type(A)

>>> type(B)

>>>

>>> import sys

>>> sys.getsizeof(A()) # размер в байтах.

64

>>> sys.getsizeof(B())

72

Flask — это веб-микрофреймворк, который объединяет Werkzeug и Jinja2, оба они написаны Армином Роначером (Armin Ronacher). Создавался шутки ради и был выпущен 1 апреля 2010 года, но быстро стал одним из самых популярных фреймворков Python. Армин несколькими годами ранее (в 2007 году) выпустил Werkzeug, преподнеся его как «швейцарский нож для веб-разработки на Python», и (как мы предполагаем) был немного расстроен тем, что он приживался слишком медленно. Идея Werkzeug заключалась в том, чтобы отвязать WSGI от всего остального, дабы разработчики могли подключать вспомогательные программы по своему выбору. Армин еще не догадывался, насколько нам нужны дополнительные «рельсы»[71].

Читаем код фреймворка

Программный фреймворк похож на физический фреймворк — предлагает структуру для создания приложения WSGI[72]: пользователь библиотеки предоставляет компоненты, которые основное приложение Flask запускает. Наша цель при чтении кода — понять структуру фреймворка и его возможности.

Получаем Flask с GitHub:

$ git clone https://github.com/pallets/flask.git

$ virtualenv venv # вы можете использовать Python 3, но это не рекомендуется

$ source venv/bin/activate

(venv)$ cd flask

(venv)$ pip install — editable.

(venv)$ pip install — r test-requirements.txt # Required for unit tests

(venv)$ py.test tests # Запускаем юнит-тесты

Онлайн-документация к Flask (http://flask.pocoo.org/) начинается с реализации веб-приложения длиной семь строк, затем приводится общее описание Flask: это основанный на Unicode и совместимый с WSGI фреймворк, который использует Jinja2 для создания шаблонов HTML и Werkzeug — для работы со вспомогательными программами WSGI, например маршрутизации URL. Имеет встроенные инструменты для разработки и тестирования.

Вам также доступны полезные руководства, поэтому следующий шаг сделать нетрудно.

Мы можем запустить пример flaskr, который загрузили с репозитория GitHub. В документах говорится, что это небольшой сайт для ведения блога. Находясь в верхнем каталоге Flask, запустите следующие команды:

(venv)$ cd examples/flaskr/

(venv)$ py.test test_flaskr.py # Тесты должны проходить

(venv)$ export FLASK_APP=flaskr

(venv)$ flask initdb

(venv)$ flask run

Итоговой целью Flask является создание веб-приложения, поэтому он не особо отличается от приложений командной строки Diamond и HowDoI. Вместо того чтобы привести еще одну схему, иллюстрирующую прохождение потока выполнения по функциям, мы пройдемся с помощью отладчика по приложению-примеру flaskr. Для этого нам нужен pdb — отладчик Python (находится в стандартной библиотеке).

Для начала добавьте точку останова в файле Flaskr.py, которая будет активизирована, когда поток выполнения ее достигнет, что заставит интерактивную сессию войти в отладчик:

@app.route('/')

def show_entries():

····import pdb; pdb.set_trace() ## Здесь поставьте точку останова.

····db = get_db()

····cur = db.execute('select title, text from entries order by id desc')

····entries = cur.fetchall()

····return render_template('show_entries.html', entries=entries)

Закройте файл и введите python в командной строке, дабы войти в интерактивную сессию. Чтобы не запускать сервер, используйте внутренние вспомогательные программы для тестирования Flask — для симуляции запроса HTTP GET к каталогу /, куда мы только что поместили отладчик:

>>> import flaskr

>>> client = flaskr.app.test_client()

>>> client.get('/')

> /[… truncated path…]/flask/examples/flaskr/flaskr.py(74)show_entries()

-> db = get_db()

(Pdb)

Последние три строки мы получили от pdb: мы видим путь (к Flaskr.py), номер строки (74) и имя метода (show_entries()), где мы остановились. Строка (-> db = get_db()) показывает выражение, которое будет выполнено следующим, если сделаем в еще один шаг в отладчике. Приглашение (Pdb) указывает на то, что мы используем отладчик pdb.

Мы можем подняться или опуститься по стеку[73], введя в командной строке u или d соответственно. Просмотрите документацию к pdb (https://docs.python.org/library/pdb.html) под заголовком «Команды отладчика», чтобы получить полный список команд, с которыми можно работать. Мы также можем ввести имена переменных, чтобы увидеть их значения, и любую другую команду Python; мы даже можем указать переменным другие значения до того, как продолжим выполнение кода.

Если мы поднимемся по стеку на один шаг, то увидим, что вызвало функцию show_entries() (с помощью точки останова, которую мы только что установили): это объект flask.app.Flask, имеющий словарь с именем view_functions, который соотносит строковые имена (вроде 'show_entries') с функциями. Мы также увидим, что функция show_entries() была вызвана с **req.view_args.

Мы можем узнать, чем является req.view_args, в интерактивной командной строке отладчика, просто введя нужное имя (это пустой словарь — {}, то есть аргументов нет):

(Pdb) u

> /[… truncated path…]/flask/flask/app.py(1610)dispatch_request()

-> return self.view_functions[rule.endpoint](**req.view_args)

(Pdb) type(self)

(Pdb) type(self.view_functions)

(Pdb) self.view_functions

{'add_entry': ,

'show_entries': , [… truncated…]

'login': }

(Pdb) rule.endpoint

'show_entries'

(Pdb) req.view_args

{}

Одновременно с отладкой мы можем открыть файл исходного кода и следовать по нему. Если мы продолжим подниматься по стеку, то увидим, где вызвано приложение WSGI:

(Pdb) u

> /[… truncated path…]/flask/flask/app.py(1624)full_dispatch_request()

-> rv = self.dispatch_request()

(Pdb) u

> /[… truncated path…]/flask/flask/app.py(1973)wsgi_app()

-> response = self.full_dispatch_request()

(Pdb) u

> /[… truncated path…]/flask/flask/app.py(1985)__call__()

-> return self.wsgi_app(environ, start_response)

Если мы продолжим вводить u, то окажемся в модуле тестирования, который был использован для создания фальшивого клиента без запуска сервера, — мы достигли конца стека. Мы узнали, что приложение flaskr отправляется изнутри объекта класса flask.app.Flask, строка 1985 файла Flask/Flask/app.py. Перед вами эта функция:

Это строка 1973, определенная в отладчике.

Это строка 1985, также определенная в отладчике. Сервер WSGI получит объект Flask как приложение и будет вызывать его всякий раз, когда приходит соответствующий запрос (с помощью отладчика мы нашли точку входа в код).

Мы используем отладчик точно так же, как граф вызовов для HowDoI: следуем вызовам функций (это в принципе не отличается от чтения самого кода). Ценность отладчика заключается в том, что мы не видим лишнего кода, который может отвлечь нас или запутать. Используйте тот подход, который наиболее эффективен для вас.

После того как мы поднялись по стеку с помощью команды u, можем вернуться вниз с помощью команды d — и снова окажемся у точки останова, помеченной *** Newest frame:

> /[… truncated path…]/flask/examples/flaskr/flaskr.py(74)show_entries()

-> db = get_db()

(Pdb) d *** Newest frame

Далее можем перейти через вызов функции с помощью команды n (next — «далее») или же сделать минимально возможный шаг с помощью команды s (step — «шаг»):

Тема на этом не заканчивается, но демонстрировать весь материал довольно утомительно. Вот что мы узнали.

Существует объект Flask.g, который при более детальном рассмотрении оказывается глобальным контекстом (при этом он является локальным для объекта Flask). Он предназначен для хранения соединений с базой данных и других устойчивых объектов вроде cookie, которые должны «жить» дольше, чем методы класса Flask. Использование словаря подобным образом позволяет хранить переменные за пределами пространства имен приложения Flask, избегая «столкновений» имен.

Функция render_template() находится в конце определения функции в модуле flaskr.py. Это означает, что мы, по сути, закончили работу — возвращаемое значение отправляется вызывающей функции из объекта Flask, который мы видели при подъеме по стеку. Поэтому мы пропустим остальную часть.

Отладчик полезно использовать локально в том месте, которое вы проверяете, чтобы точно понять, что происходит в коде до и после выбранной пользователем точки. Одной из основных функций является возможность изменять переменные на ходу (любой код Python работает в отладчике), после чего вы можете продолжить выполнение кода.

Примеры стиля из Flask

Большая часть примеров стиля из главы 4 уже была рассмотрена, поэтому для Flask мы продемонстрируем всего один — реализацию элегантных и простых декораторов маршрутизации.

Декораторы для маршрутизации во Flask (красивое лучше, чем уродливое). Декораторы для маршрутизации во Flask добавляют маршрутизацию URL к целевым функциям, например так:

@app.route('/')

def index():

····pass

При отправке запроса приложение Flask будет использовать маршрутизацию URL для определения корректной функции, которая нужна для генерации ответа. Синтаксис декоратора позволяет хранить логику маршрутизации за пределами целевой функции, поддерживает функции flat, а его использование интуитивно.

Делать это вовсе необязательно — он существует только для того, чтобы предоставить пользователю данную функциональность API. Рассмотрим исходный код метода основного класса Flask, определенного в файле Flask/Flask/app.py.

_PackageBoundObject настраивает файловую структуру для импорта шаблонов HTML, статических файлов и другого содержимого, основываясь на значениях конфигурации, указывающих их местоположение относительно местоположения модуля приложения (например, app.py).

Почему бы не назвать его декоратором? Он выполняет те же функции.

Это функция, которая добавляет URL в сопоставление, содержащее все правила. Единственное предназначение Flask.route — предоставить удобный декоратор для пользователей библиотеки.

Примеры структуры из Flask

Основной посыл для обоих примеров структуры для Flask — модульность. Flask целенаправленно структурирован так, чтобы вы могли расширять и модифицировать практически все что угодно — от способа кодирования/декодирования строк JSON (Flask дополняет функциональность стандартной библиотеки для работы с JSON возможностью задавать кодировки для объектов datetime и UUID) до классов, использованных для маршрутизации URL.

Стандарты, характерные для приложения (простое лучше, чем сложное)

Flask и Werkzeug имеют модуль wrappers.py. Он нужен, чтобы добавить соответствующие значения по умолчанию во Flask, фреймворк для веб-приложений, которые будут дополнять общую библиотеку вспомогательных программ для приложений WSGI от Werkzeug. Во Flask создаются подклассы для Request и Response Werkzeug для того, чтобы добавлять функциональность, характерную для веб-приложений. Например, объект Response из файла Flask/Flask/wrappers.py выглядит так:

Класс Response от Werkzeug импортируется как ResponseBase, эта деталь стиля делает предназначение класса очевидным и позволяет новому подклассу Response получить его имя.

Возможность создать подкласс flask.wrappers.Response, а также способ выполнения этой задачи подробно описаны в строках документации. Когда вы реализуете подобную функциональность, важно помнить о документации, в противном случае пользователи не будут знать о том, что такая возможность существует.

На этом изменения в классе Response заканчиваются. Класс Request изменился больше, но мы не будем показывать его в этой главе, чтобы не раздувать ее размер.

В этой небольшой интерактивной сессии показывается, что изменилось в классе Response:

>>> import werkzeug

>>> import flask

>>>

>>> werkzeug.wrappers.Response.default_mimetype

'text/plain'

>>> flask.wrappers.Response.default_mimetype

'text/html'

>>> r1 = werkzeug.wrappers.Response('hello', mimetype='text/html')

>>> r1.mimetype

u'text/html'

>>> r1.default_mimetype

'text/plain'

>>> r1 = werkzeug.wrappers.Response('hello')

>>> r1.mimetype

'text/plain'

Идея изменения mime-типа по умолчанию заключается в том, чтобы позволить пользователям Flask писать меньше кода при сборке объектов ответа, которые содержат HTML (ожидаемые вариант использования Flask). Разумные значения по умолчанию делают ваш код гораздо более понятным для среднестатистического пользователя.

Модульность (еще одна отличная штука). Строки документации для flask.wrappers.Response сообщают пользователям, что они могут создать подкласс объекта Response и использовать его в основном объекте Flask.

В следующем фрагменте кода Flask/Flask/app.py мы приведем другие примеры модульности Flask.

Здесь можно заменить пользовательский класс Request.

А здесь вы можете определить пользовательский класс Response. Эти атрибуты относятся к классу Flask (а не к объекту), имеют понятные имена, благодаря которым можно узнать их назначение.

Класс Environment является подклассом класса Environment из Jinja2, который может понимать Flask Blueprints («Эскизы Flask»), что позволяет создавать более крупные приложения, состоящие из множества файлов.

Существуют и другие проявления модульности, которые здесь не показаны, поскольку мы не хотим повторяться.

Если вы взглянете на определение класса Flask, то увидите, где создаются и используются объекты этих классов. Мы показали их для того, чтобы вы поняли, что эти определения классов не должны быть доступны пользователю, — этот выбор был явно сделан при выборе структуры, чтобы дать пользователю больше возможностей контролировать поведение Flask. Когда пользователи говорят о модульности Flask, они имеют в виду не только применение любого бэкенда для базы данных. Подразумевается, что вы можете подключать и применять разные классы.

Вы увидели примеры качественно написанного кода, который следует принципам дзен. Мы рекомендуем взглянуть на полный код перечисленных здесь программ: лучший способ стать хорошим программистом — читать отличный код. И помните: когда писать код становится трудно, используй исходники, Люк![74]

Упаковка кода дистрибутива означает создание необходимой структуры файла, добавление требуемых файлов и определение подходящих переменных для comform, релевантных PEP, и текущих правил хорошего тона, описанных в разделе Packaging and Distributing Projects («Упаковка и распространение проектов») в Python Packaging Guide[76], или требования к упаковке для других репозиториев вроде http://anaconda.org/.

Conda

Если у вас установлен дистрибутив Python от Anaconda, вы все еще можете использовать pip и PyPI, но вашим менеджером пакетов по умолчанию будет conda, а репозиторием пакетов — http://anaconda.org/. При сборке пакетов мы рекомендуем следовать руководству, расположенному по адресу http://bit.ly/building-conda. Оно заканчивается инструкциями, как загружать пакеты на Anaconda.org.

Если вы создаете библиотеку для научных или статистических приложений — даже если сами не используете Anaconda, — вам понадобится установить дистрибутив для Anaconda, чтобы получить доступ к широкой аудитории научных работников, предпринимателей и пользователей Windows, которые пользуются Anaconda для получения бинарных файлов без лишних забот.

PyPI

Надежная взаимосвязанная система инструментов вроде PyPI и pip позволяет разработчикам максимально легко загружать и устанавливать пакеты как для экспериментов, так и для создания крупных профессиональных систем.

Если вы пишете модуль Python с открытым исходным кодом, PyPI (http://pypi.python.org/), более известный как The Cheeseshop, — походящее место для того, чтобы его разместить[77]. Если для упаковки кода вы выбрали не PyPI, другим разработчикам будет сложнее его найти и использовать как часть их существующих процессов. Они будут относиться к таким проектам с подозрением, поскольку посчитают, что либо проектом плохо управляют и он не готов к релизу, либо проект заброшен.

Правильную и актуальную информацию об упаковке Python вы можете получить из руководства Python Packaging Guide, поддерживаемого PyPA (https://packaging.python.org/en/latest/).

Пример проекта PyPA по адресу https://github.com/pypa/sampleproject демонстрирует современные правила хорошего тона, касающиеся упаковки проекта Python. В комментариях к модулю setup.py (https://github.com/pypa/sampleproject/blob/master/setup.py) вы найдете полезные советы и описание важных способов управления для PEP. Общая структура файлов организована согласно требованиям, для каждого файла имеются полезные комментарии, повествующие об их предназначении и о том, что должно в них содержаться.

Файл README отсылает нас к руководству по упаковке (https://packaging.python.org/) и к руководству по упаковке и распространению (https://packaging.python.org/en/latest/distributing.html).

С 2011 года PyPA хорошо поработало для того, чтобы избавиться от заметной путаницы (http://stackoverflow.com/questions/6344076) и прекратить дискуссию (http://stackoverflow.com/questions/3220404) о том, какой именно способ распространения, упаковки и установки библиотек Python можно назвать стандартным. pip был выбран в качестве установщика пакетов по умолчанию в PEP 453 (https://www.python.org/dev/peps/pep-0453/), он устанавливается вместе с Python 3.4 (выпущен в 2014 году) и более поздними версиями[78].

Каждый из этих инструментов может выполнять задачи, которые другим не под силу, а для более старых систем все еще может понадобиться инструмент easy_install. В таблице от PyPA, расположенной по адресу http://packaging.python.org/en/latest/pip_easy_install/, сравниваются pip и easy_install и описываются возможности каждого инструмента.

При разработке собственного кода для установки вам понадобится использовать команду pip install — editable, что позволит редактировать код без переустановки.

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

Предположим, что вы хотите установить пакет, который называется MyPackage.tar.gz. Имеется следующая иерархия каталогов:

|- archive/

·····|- MyPackage/

··········|- MyPackage.tar.gz

Вы можете запустить сервер HTTP из каталога archive, введя следующую команду в оболочке:

$ cd archive

$ python3 — m SimpleHTTPServer 9000

Это запустит простой сервер HTTP на порту 9000 и перечислит все пакеты (в нашем случае MyPackage). Теперь вы можете установить MyPackage с помощью любого установщика пакетов для Python. Используйте pip в командной строке:

$ pip install — extra-index-url=http://127.0.0.1:9000/ MyPackage

$ pip install http://127.0.0.1:9000/MyPackage.tar.gz

Pypiserver (https://pypi.python.org/pypi/pypiserver) — это минимальный сервер, совместимый с PyPI. Он может использоваться при обслуживании набора пакетов для easy_install или pip. Содержит полезную функциональность вроде административной команды (-U), которая обновит все пакеты до самых последних версий, имеющихся в PyPI.

Помимо вышеперечисленных вариантов, вы можете разместить личный сервер PyPI на Simple Storage Service от Amazon, Amazon S3 (https://aws.amazon.com/s3/). Для этого вам понадобятся учетная запись для Amazon Web Service (AWS) и сегмент S3. Убедитесь, что вы следуете правилам именования сегмента (http://bit.ly/rules-bucket-naming) (вы, конечно, сможете создать сегмент, который нарушает правила именования, но не получите к нему доступ). Для того чтобы использовать ваш сегмент, сначала создайте виртуальную среду на собственной машине и установите требуемые сторонние библиотеки с помощью PyPI или другого источника. Затем установите pip2pi:

$ pip install git+https://github.com/wolever/pip2pi.git

Далее следуйте указаниям файла README для pip2pi, где вы сможете прочесть о командах pip2tgz и dir2pi. Вам нужно запустить либо эту команду:

$ pip2tgz packages/ YourPackage+

либо эти две:

$ pip2tgz packages/ — r requirements.txt

$ dir2pi packages/

Теперь загружайте свои файлы. Используйте клиент вроде Cyberduck (https://duck.sh/), чтобы каталог с пакетами синхронизировать с вашим сегментом S3. Убедитесь, что вместе с новыми файлами и папками вы загружаете файл packages/simple/index.html.

По умолчанию при загрузке новых файлов в сегмент S3 им присваивается уровень доступа «только для пользователей». Если при попытке установить пакет вы получите код HTTP 403, удостоверьтесь, что правильно настроили уровень доступа: используйте веб-консоль от Amazon, чтобы установить уровень EVERYONE (разрешает чтение всех файлов). Установите ваш пакет с помощью следующей команды:

$ pip install \

··-index-url=http://your-s3-bucket/packages/simple/ \

··YourPackage+

Существует возможность получать код непосредственно из системы контроля версий с помощью инструмента pip (для этого следуйте инструкциям по адресу http://bit.ly/vcs-support). Этот способ — альтернатива размещению личного PyPI. Рассмотрим пример команды, использующей pip для получения проекта с GitHub:

$ pip install git+git://git.myproject.org/MyProject#egg=MyProject

В этой команде egg нужно заменить — он носит имя каталога вашего проекта, который вы хотите установить.

Фраза «заморозить код» означает «создать отдельный исполняемый пакет, который можно распространять конечным пользователям, на чьих компьютерах не установлен Python». Распространяемый файл или пакет содержит как код приложения, так и интерпретатор Python.

Приложения вроде Dropbox (https://www.dropbox.com/en/help/65), Eve Online (http://www.eveonline.com/), Civilization IV (https://www.civilization.com/en/games/civilization-iv/) и клиента BitTorrent (http://www.bittorrent.com/) (в основном они написаны на Python) делают это.

Преимущество распространения кода таким способом в том, что ваше приложение будет работать независимо от того, установлена ли на компьютере пользователя требуемая (или хоть какая-нибудь) версия Python. В Windows и для многих дистрибутивов Linux и OS X корректная версия Python не установлена заранее. Помимо этого, программное обеспечение конечного пользователя всегда должно иметь исполняемый формат. Файлы с расширением. py предназначены для программных инженеров и системных администраторов.

Недостаток у заморозки один — она увеличивает размер вашего дистрибутива на 2–12 Мбайт. Кроме того, вам придется отправлять обновленные версии вашего приложения, когда будут выходить обновления безопасности к Python.

Мы сравним популярные инструменты для заморозки в табл. 6.1. Все они взаимодействуют со стандартной библиотекой Python. Они не могут выполнять кросс-платформенную заморозку[79], поэтому вы должны проводить сборки на целевых платформах.

Инструменты перечислены в том порядке, в каком описаны в этом разделе. PyInstaller и cx_Freeze могут использоваться на всех платформах, py2app работает только для OS X, py2exe — только для Windows, а bbFreeze может работать на UNIX-подобных системах и для Windows, но не для OS X (он еще не портирован на Python 3). Он может генерировать архивы egg, если вам нужна такая функциональность для вашей легаси-системы.

* pkg_resources (https://pythonhosted.org/setuptools/pkg_resources.html) — это отдельный модуль, поставляющийся с Setuptools, который может использоваться для автоматического поиска зависимостей. При заморозке кода возникают трудности, поскольку сложно вручную находить динамически загруженные зависимости статического кода. PyInstaller, например, только говорит о том, что все будет хорошо, когда анализ проводится для egg-архива.

** Режим одного файла — это способ размещения пакетов приложения и всех его зависимостей в едином исполняемом файле в ОС Windows. InnoSetup (http://www.jrsoftware.org/isinfo.php) и Nullsoft Scriptable Install System (NSIS) (http://nsis.sourceforge.net/Main_Page) — это популярные инструменты для создания установщиков, которые могут объединять код в единый файл с расширением. exe.

PyInstaller

PyInstaller (http://www.pyinstaller.org/) может быть использован для создания приложений для OS X, Windows и Linux. Его основное предназначение — быть совместимым со сторонними пакетами после установки, поэтому заморозка сразу работает[80]. По адресу https://github.com/pyinstaller/pyinstaller/wiki/Supported-Packages перечислены пакеты, поддерживаемые PyInstaller. Список поддерживаемых графических библиотек содержит Pillow, pygame, PyOpenGL, PyGTK, PyQT4, PyQT5, PySide (за исключением надстроек для Qt) и wxPython. Поддерживаются также инструменты NumPy, Matplotlib, Pandas и SciPy.

PyInstaller имеет модифицированную лицензию GPL (https://github.com/pyinstaller/pyinstaller/wiki/License) «с особым исключением, которое позволяет [всем] использовать PyInstaller для сборки и распространения небесплатных программ (включая коммерческие)», поэтому лицензии, которым вы должны подчиняться, будут зависеть от используемых вами при разработке кода библиотек. Команда разработчиков PyInstaller даже предоставляет инструкции, как спрятать исходный код (http://bit.ly/hiding-source-code), для тех, кто создает коммерческие приложения или хочет, чтобы никто не изменял их код. Обязательно прочтите текст лицензии (проконсультируйтесь с адвокатом, если это важно, или воспользуйтесь ресурсом https://tldrlegal.com/, если это неважно), если вам нужно модифицировать их исходный код для того, чтобы создать собственное приложение, поскольку вам, возможно, придется поделиться изменениями.

Руководство к PyInstaller (http://pyinstaller.readthedocs.org/) содержит достаточно информации. Взгляните на страницу http://bit.ly/pyinstaller-reqs, где приводятся требования для PyInstaller, чтобы убедиться, что ваша система совместима: для Windows вам потребуется версия XP или выше, для систем Linux — несколько консольных приложений (списки документации, где вы можете их найти), а для OS X — версия 10.7 (Lion) или выше.

Вы можете использовать Wine (эмулятор Windows) для кросс-компиляции для Windows при работе с Linux или OS X.

Чтобы установить PyInstaller, используйте pip из той виртуальной среды, из которой будете строить ваше приложение:

$ pip install pyinstaller

Для создания стандартного исполняемого файла из модуля script.py введите следующую команду:

$ pyinstaller script.py

Для создания оконного приложения для OS X или Windows задайте флаг — windowed в командной строке:

$ pyinstaller — windowed script.spec

Появляются две новые папки и файл в том же каталоге, где вы выполнили команду pyinstaller:

• файл с расширением. spec, который можно запустить с помощью PyInstaller для повторного создания сборки;

• каталог сборки, в котором хранятся некоторые файлы журнала;

• каталог dist, в котором хранятся главный исполняемый файл и некоторые зависимые библиотеки Python.

PyInstaller помещает все библиотеки Python, используемые вашим приложением, в каталог dist, поэтому, когда начнете распространять исполняемый файл, не забудьте, что вы должны распространять весь каталог dist.

Файл script.spec можно изменить для того, чтобы настроить сборку (http://pythonhosted.org/PyInstaller/#spec-file-operation). Вы можете сделать следующее:

• связать файлы данных и исполняемые файлы;

• включить библиотеки времени выполнения (файлы с расширением. dll или. so), которые PyInstaller не может определить автоматически;

• добавить для исполняемого файла флаги времени выполнения Python.

Это полезно, поскольку теперь файл можно хранить с помощью системы контроля версий, что упрощает создание будущих сборок. Вики-страница PyInstaller содержит рецепты сборки (https://github.com/pyinstaller/pyinstaller/wiki/Recipes) для некоторых распространенных приложений, включая Django, PyQt4, а также функционал по подписанию кода для Windows и OS X. Там же вы найдете последнюю версию руководства для PyInstaller. Теперь отредактированный файл script.spec можно запускать как аргумент для pyinstaller (вместо повторного использования script.py):

$ pyinstaller script.spec

cx_Freeze

Как и PyInstaller, cx_Freeze (https://cx-freeze.readthedocs.org/en/latest/) может замораживать проекты Python для ОС Linux, OS X и Windows. Однако команда разработчиков cx_Freeze не рекомендует компилировать для Windows с помощью Wine, поскольку им пришлось вручную скопировать некоторые файлы, чтобы приложение работало. Для установки спользуйте pip:

$ pip install cx_Freeze

Самый простой способ создать исполняемый файл — запустить cxfreeze из командной строки, но есть и другие варианты (вы можете использовать систему контроля версий), если вы пишете сценарий setup.py.

Это тот же самый файл setup.py, что и для модуля distutils из стандартной библиотеки Python: cx_Freeze расширяет distutils таким образом, чтобы предоставлять несколько дополнительных команд (и модифицировать некоторые другие).

Данные параметры можно передавать через командную строку, сценарий установки или с помощью конфигурационного файла setup.cfg (https://docs.python.org/3/distutils/configfile.html).

Сценарий cxfreeze-quickstart создает простой файл setup.py, который может быть изменен и сохранен в системе контроля версий для будущих сборок. Рассмотрим пример сессии для сценария с именем hello.py:

$ cxfreeze-quickstart

Project name: hello_world

Version [1.0]:

Description: "This application says hello."

Python file to make executable from: hello.py

Executable file name [hello]:

(C)onsole application, (G)UI application, or (S)ervice [C]:

Save setup script to [setup.py]:

Setup script written to setup.py; run it as:

····python setup.py build

Run this now [n]?

Теперь у нас есть сценарий установки и мы можем изменить его в соответствии с нуждами нашего приложения. Параметры вы можете найти в документации к cx_Freeze в разделе distutils setup scripts (https://cx-freeze.readthedocs.org/en/latest/distutils.html). Существуют также пример сценария setup.py и работающие приложения с минимальной функциональностью, которые показывают, как замораживать приложения, использующие PyQT4, Tkinter, wxPython, Matplotlib, Zope и другие библиотеки. Вы можете найти их в каталоге samples/ исходного кода cx_Freeze (https://bitbucket.org/anthony_tuininga/cx_freeze/src): перейдите из каталога высшего уровня в cx_Freeze/cx_Freeze/samples/. Код также поставляется с установленной библиотекой. Вы можете получить путь, введя следующую команду:

$ python — c 'import cx_Freeze; print(cx_Freeze.__path__[0])'

Когда закончите редактировать файл setup.py, можете использовать его для создания собственного исполняемого файла с помощью одной из этих команд:

Этот параметр предназначен для создания исполняемого файла для командной строки.

Этот параметр модифицирован cx_Freeze, чтобы вы могли обрабатывать исполняемые файлы Windows и их зависимости.

Этот параметр модифицирован, чтобы вы могли гарантировать, что пакеты для Linux создаются с подходящей архитектурой для текущей платформы.

Этот параметр позволяет создать пакет для отдельного оконного приложения для OS X (.app), содержащий зависимости и исполняемый файл.

Этот параметр позволяет создать пакет app и пакет приложения, которые затем будут упакованы в образ диска DMG.

py2app

py2app (https://pythonhosted.org/py2app) позволяет создать исполняемые файлы для OS X. Как и cx_Freeze, он расширяет distutils, добавляя новую команду py2app. Чтобы установить ее, используйте pip:

$ pip install py2app

Далее автоматически сгенерируйте сценарий setup.py с помощью команды py2applet:

$ py2applet — make-setup hello.py

Wrote setup.py

Вы создали простой файл setup.py, который можно модифицировать согласно вашим потребностям. Вы можете найти примеры работающих приложений с минимальной функциональностью и соответствующими сценариями setup.py, которые используют библиотеки вроде PyObjC, PyOpenGL, pygame, PySide, PyQT, Tkinter и wxPython в исходном коде py2app (https://bitbucket.org/ronaldoussoren/py2app/src/). Для этого перейдите из каталога верхнего уровня в каталог py2app/examples/.

Далее запустите файл setup.py с помощью команды py2app, чтобы создать два каталога — build и dist. Убедитесь, что вы очистили каталоги перед выполнением повторной сборки. Команда выглядит так:

$ rm — rf build dist

$ python setup.py py2app

Чтобы прочесть дополнительную документацию, обратитесь к руководству py2app (https://pythonhosted.org/py2app/tutorial.html). Сборка может завершиться генерацией исключения AttributeError. Если это произошло, прочтите в руководстве об использовании py2app (http://bit.ly/py2app-tutorial) — запись переменных scan_code и load_module, возможно, нужно начинать с нижнего подчеркивания: _scan_code и _load_module.

py2exe

py2exe (https://pypi.python.org/pypi/py2exe) создает исполняемые файлы для Windows. Он очень популярен, клиент BitTorrent (http://www.bittorrent.com/) для Windows был создан с помощью py2exe. Как и cx_Freeze и py2app, он расширяет distutils, в этом случае добавляется команда py2exe. Если вам нужно использовать его с Python 2, загрузите более старую версию py2exe из sourceforge (https://sourceforge.net/projects/py2exe/). В противном случае (если у вас установлен Python 3.3+) используйте pip:

$ pip install py2exe

Руководство к py2exe (http://www.py2exe.org/index.cgi/Tutorial) составлено превосходно (возможно, потому что документация размещена на вики-странице, а не в системе контроля версий). Самый простой сценарий setup.py выглядит так:

from distutils.core import setup

import py2exe

setup(

····windows=[{'script': 'hello.py'}],

)

В документации перечислены все параметры конфигурации для py2exe (http://www.py2exe.org/index.cgi/ListOfOptions), а также приведены детальные заметки о том, как (опционально) включить иконки (http://www.py2exe.org/index.cgi/CustomIcons) или создать единый исполняемый файл (http://www.py2exe.org/index.cgi/SingleFileExecutable). В зависимости от лицензии для Microsoft Visual C++ у вас может быть (или не быть) возможность распространять библиотеки среды выполнения для Microsoft Visual C++ вместе с вашим кодом. Если вам это доступно, изучите инструкции по распространению DLL Visual C++ вместе с исполняемыми файлами; в противном случае вы можете предоставить пользователям вашего приложения способ загрузить и установить Microsoft Visual C++ 2008 redistributable packge (http://www.py2exe.org/index.cgi/Tutorial#Step52) или Visual C++ 2010 redistributable packge (http://bit.ly/ms-visual-10), если вы используете Python 3.3 или выше.

После того как вы подкорректируете свой файл установки, можете сгенерировать исполняемый файл в каталог dist, введя следующую команду:

$ python setup.py py2exe

bbFreeze

Библиотеку bbFreeze (https://pypi.python.org/pypi/bbfreeze) в данное время никто не поддерживает, и она не была портирована на Python 3, но ее все еще часто загружают. Как и библиотеки cx_Freeze, py2app и py2exe, она расширяет модуль distutils, добавляя команду bbfreeze. Фактически более старые версии bbFreeze были основаны на cx_Freeze. Эта библиотека может пригодиться тем, кто поддерживает легаси-системы и хотел бы упаковывать сборки в архивы egg, чтобы затем использовать их в своей инфраструктуре. Для установки используйте команду pip:

$ pip install bbfreeze # bbFreeze can't work with Python3

Для нее практически нет документации, но вы можете найти алгоритмы сборки (https://github.com/schmir/bbfreeze/blob/master/bbfreeze/recipes.py) для Flup (https://pypi.python.org/pypi/flup), Django, Twisted, Matplotlib, GTK и Tkinter, а также многие другие. Чтобы создать исполняемые бинарные файлы, используйте команду bdist_bbfreeze следующим образом:

$ bdist_bbfreeze hello.py

Она создаст каталог dist по адресу, где была запущена bbfreeze, в этом каталоге будут находиться интерпретатор Python и исполняемый файл с таким же именем, что и сценарий (в нашем случае hello.py).

Для того чтобы сгенерировать архив egg, используйте новую команду distutils:

$ python setup.py bdist_bbfreeze

Существуют и другие варианты, например разметка сборок как снепшотов или ежедневные сборки. Для того чтобы получить больше информации об использовании библиотеки, воспользуйтесь флагом — help:

$ python setup.py bdist_bbfreeze — help

Для более тонкой настройки задействуйте класс bbfreeze.Freezer (этот способ использования bbfreeze предпочтительный). Он имеет флаги, которые указывают, применять ли сжатие в созданном ZIP-файле, включать ли интерпретатор Python, а также какие сценарии выбрать.