chroot — это подобие команды virtualenv на системном уровне: позволяет сделать так, чтобы корневой каталог (/) располагался по адресу, указанному пользователем, а не в реальном корневом каталоге (это предоставляет пользователю отдельное пространство (https://en.wikipedia.org/wiki/User-space)).
Docker больше не использует chroot и даже Linux Containers (позволяет включить в число доступных образов Docker машины Citrix и Solaris), но принцип работы контейнеров Docker Containers не изменился. Их конфигурационные файлы называются Dockerfiles (https://docs.docker.com/engine/reference/builder/), с их помощью создаются образы Docker (https://docs.docker.com/engine/userguide/containers/dockerimages/), которые можно разместить в Docker Hub (https://docs.docker.com/docker-hub/), репозитории пакетов Docker (аналогичен PyPI).
Корректно сконфигурированные образы Docker занимают гораздо меньше места, чем среды, созданные с помощью Buildout или conda, поскольку Docker использует файловую систему AUFS, хранящую «разность» образа, а не сам образ. Поэтому, если вы хотите построить и протестировать свой пакет для нескольких версий зависимости, можете создать основной образ Docker с виртуальной средой[35] (средой Buildout или conda), содержащей все остальные зависимости.
Вы унаследуете от этого образа все остальные образы, добавив на последнем уровне одну изменяющуюся зависимость. В результате все унаследованные контейнеры будут содержать только отличающиеся библиотеки, разделяя при этом содержимое основного образа. Для получения более подробной информации обратитесь к документации Docker по адресу https://docs.docker.com/.
Часть II. Переходим к делу
Теперь у нас есть интерпретатор Python, виртуальные среды и редактор или IDE, так что мы готовы заняться делом. В этой части книги мы не будем изучать язык (в разделе «Изучаем Python» приложения перечислены отличные ресурсы, которые помогут вам в этом). Мы хотим, чтобы после прочтения вы почувствовали себя настоящим программистом Python, знающим все хитрости лучших питонистов. В эту часть входят следующие главы.
• Глава 4 «Пишем отличный код». Мы кратко рассмотрим стиль, соглашения, идиомы и подводные камни.
• Глава 5 «Читаем отличный код». Мы проведем для вас экскурсию по нашим любимым библиотекам (может, это вдохновит вас на дальнейшее чтение хорошего кода?).
• Глава 6 «Отправляем отличный код». Мы кратко поговорим о Python Packaging Authority и о том, как загружать бинарные файлы в PyPI, рассмотрим варианты сборки и отправки исполняемых файлов.
Глава 4. Пишем отличный код
В этой главе продемонстрированы лучшие приемы написания отличного кода 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. Для установки этой программы введите в терминале такую команду: