Кеннет Рейтц – Автостопом по Python (страница 40)

>>> r1.mimetype

'text/plain'

Идея изменения mime-типа по умолчанию заключается в том, чтобы позволить пользователям Flask писать меньше кода при сборке объектов ответа, которые содержат HTML (ожидаемые вариант использования Flask). Разумные значения по умолчанию делают ваш код гораздо более понятным для среднестатистического пользователя.

Иногда значения по умолчанию нужны не только для простоты использования. Например, Flask устанавливает ключи, необходимые для определения числа посетителей и безопасной коммуникации, по умолчанию равными Null. Если ключ имеет значение null, то приложение при попытке запуска безопасной сессии сгенерирует ошибку. Форсирование появления таких ошибок означает, что пользователи будут создавать собственные тайные ключи — другими (плохими) вариантами будет либо молчаливое разрешение использования ключа сессии, равного null, а также небезопасных способов подсчета посетителей, либо предоставление ключа по умолчанию вроде mysecretkey, который не будет обновляться (и соответственно, не будет использоваться при развертывании).

Модульность (еще одна отличная штука). Строки документации для flask.wrappers.Response сообщают пользователям, что они могут создать подкласс объекта Response и использовать его в основном объекте Flask.

В следующем фрагменте кода Flask/Flask/app.py мы приведем другие примеры модульности Flask.

Здесь можно заменить пользовательский класс Request.

А здесь вы можете определить пользовательский класс Response. Эти атрибуты относятся к классу Flask (а не к объекту), имеют понятные имена, благодаря которым можно узнать их назначение.

Класс Environment является подклассом класса Environment из Jinja2, который может понимать Flask Blueprints («Эскизы Flask»), что позволяет создавать более крупные приложения, состоящие из множества файлов.

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

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

Вы увидели примеры качественно написанного кода, который следует принципам дзен. Мы рекомендуем взглянуть на полный код перечисленных здесь программ: лучший способ стать хорошим программистом — читать отличный код. И помните: когда писать код становится трудно, используй исходники, Люк![74]

Глава 6. Отправляем отличный код

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

Система инструментов, связанная с упаковкой кода Python, стала гораздо более удобной в последние несколько лет благодаря усилиям Python Packaging Authority (PyPA)[75] (https://www.pypa.io/) — это сообщество, которое поддерживает pip, Python Package Index (PyPI), а также большую часть инфраструктуры, связанной с упаковкой в Python. Их документация, касающаяся упаковки (https://packaging.python.org/), отлично составлена, поэтому мы кратко рассмотрим два способа размещения пакетов на частном сайте, а также поговорим о том, как загружать код на Anaconda.org — коммерческий аналог PyPI, запущенный Continuum Analytics.

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

Это приемлемо при распространении кода для других разработчиков, но не подходит для распространения приложения пользователям, не являющимся программистами. Для этого вам нужно использовать один из инструментов, показанных в разделе «Замораживаем ваш код».

Тем, кто создает пакеты Python для Linux, нелишне обратить внимание на пакет distro (например, файл с расширением. deb на Debian/Ubuntu; он называется дистрибутивом в документации Python). Это потребует выполнения большого объема работы, но мы предложим парочку вариантов в разделе «Упаковка для дистрибутивов, встроенных в Linux». Это похоже на заморозку, но в пакет не входит интерпретатор Python.

Наконец, мы дадим вам отличный совет в разделе «Исполняемые ZIP-файлы»: если ваш код находится в ZIP-архиве (файле с расширением. zip) и имеет определенный заголовок, вы можете просто выполнить ZIP-файл. Когда вы знаете, что у вашей целевой аудитории уже установлен Python и ваш проект состоит только из кода Python, этот вариант приемлем.

Использование словаря и Concepts

До появления PyPA не существовало единого и очевидного способа упаковки (вы можете убедиться в этом в исторической дискуссии на Stack Overflow (http://stackoverflow.com/questions/6344076)). В этой главе рассмотрим наиболее важные термины (в глоссарии PyPA (https://packaging.python.org/en/latest/glossary/) вы можете найти и другие определения).

• Зависимости. Пакеты Python перечисляют библиотеки, от которых они зависят, в файле requirements.txt (для тестирования или развертывания приложения) или в аргументе install_requires метода setuptools.setup(), когда он вызывается в файле setup.py.

В некоторых проектах могут присутствовать и другие зависимости вроде базы данных Postgres, компилятора C или разделяемого объекта библиотеки C. Они могут быть не указаны явно, но при их отсутствии сборка прервется. Если вы строите библиотеки подобным образом, вам может помочь семинар Пола Керера (Paul Kehrer), посвященный распространению скомпилированных модулей (http://bit.ly/kehrer-seminar).

• Дистрибутив. Формат распространения пакета Python (и опционально других ресурсов и метаданных), имеющий форму, которая может быть установлена и затем запущена без дальнейшей компиляции (https://packaging.python.org/en/latest/wheel_egg/).

• Egg. Egg (это формат дистрибутива) представляют собой ZIP-файлы с особой структурой, содержащие метаданные для установки. Формат был введен благодаря библиотеке Setuptools и де-факто являлся стандартом многие годы, но никогда не был официальным форматом упаковки в Python. Был заменен на wheels на момент выхода PEP 427. Вы можете прочесть все о различиях между форматами в разделе Wheel vs Egg руководства по упаковке Python.

• Wheel. Это формат дистрибутива, который является стандартом для распространения библиотек Python. Они упаковываются как ZIP-файлы с метаданными, которые pip будет использовать для установки и удаления пакета. Файл имеет расширение. whl и следует соглашению по именованию (указываются платформа, сборка и использованный интерпретатор).

Помимо установленного Python, для запуска обычных пакетов, содержащих лишь код, написанный на Python, не нужно ничего, кроме других библиотек, написанных исключительно на Python, — их можно загрузить с PyPI (https://pypi.python.org/pypi) (или Warehouse (https://warehouse.pypa.io/) — грядущего нового местоположения для PyPI). Сложности (которые мы попытались обойти, добавив дополнительные шаги по установке в главе 2) возникают, когда библиотека Python имеет зависимости за пределами Python, например в библиотеках C или системных исполняемых файлах. Инструменты вроде Buildout и Conda придут на помощь, когда дистрибутив становится сложным даже для формата are Wheel.

Упаковываем код

Упаковка кода дистрибутива означает создание необходимой структуры файла, добавление требуемых файлов и определение подходящих переменных для comform, релевантных PEP, и текущих правил хорошего тона, описанных в разделе Packaging and Distributing Projects («Упаковка и распространение проектов») в Python Packaging Guide[76], или требования к упаковке для других репозиториев вроде http://anaconda.org/.

Может быть не очень понятно, почему слово «пакет» имеет так много значений. В данный момент мы говорим о пакетах дистрибутива, которые включают (обычные для Python) пакеты, модули и дополнительные файлы, необходимые для определения релиза. Мы также иногда называем библиотеки пакетами установки; они являются высокоуровневыми каталогами пакетов, которые содержат целую библиотеку. Наконец, простой пакет — это любой каталог, содержащий файл __init__.py и другие модули (файлы с расширением *.py). PyPA поддерживает глоссарий терминов, относящихся к упаковке (https://packaging.python.org/en/latest/glossary).

Conda

Если у вас установлен дистрибутив Python от Anaconda, вы все еще можете использовать pip и PyPI, но вашим менеджером пакетов по умолчанию будет conda, а репозиторием пакетов — http://anaconda.org/. При сборке пакетов мы рекомендуем следовать руководству, расположенному по адресу http://bit.ly/building-conda. Оно заканчивается инструкциями, как загружать пакеты на Anaconda.org.