Помоги проекту - поделись книгой:
Conda
Инструмент Conda (http://conda.pydata.org/docs/) похож на pip, virtualenv и Buildout одновременно. Поставляется с дистрибутивом Anaconda и является его менеджером пакетов по умолчанию. Его можно установить с помощью pip: $ pip install conda
А pip — с помощью conda:
$ conda install pip
Пакеты хранятся в разных репозиториях (pip получает их из http://pypi.python.org, а conda из https://repo.continuum.io/), имеют разные форматы, поэтому эти инструменты невзаимозаменяемы.
В таблице по адресу http://bit.ly/conda-pip-virtualenvl, созданной компанией Continuum (создателями Anaconda), приводится сравнение трех доступных вариантов: conda, pip и virtualenv.
Инструмент conda-build, аналог Buildout от компании Continuum, может быть установлен на всех платформах, если ввести следующее: conda install conda-build
Как и в Buildout, формат файла конфигурации conda-build называется рецептом (не ограничен использованием только лишь инструментов Python). В отличие от Buildout, код указан в сценарии оболочки (это не код Python). Конфигурация приводится в формате YAML33 (это язык разметки, который понимают и люди, и машины), а не в формате ConfigParser (https://docs.python.org/3/library/configparser.html).
Основное преимущество conda перед pip и virtualenv оценят пользователи Windows — библиотеки Python, созданные как расширения на C, могут быть представлены в формате wheels (или в другом), но они практически всегда присутствуют в каталоге пакетов Anaconda (http://docs.continuum.io/anaconda/pkg-docs). Если пакет недоступен через conda, можно установить pip, а затем — пакеты, которые размещаются в PyPI.
Docker
Инструмент Docker (https://www.docker.com/) помогает изолировать среду (как virtualenv, conda или Buildout), но вместо того, чтобы предоставлять виртуальную среду, предлагает
Контейнеры Docker изначально были основаны на контейнерах Linux Containers, которые были связаны с командой оболочки chroot (https://en.wikipedia.org/wiki/Chroot).
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/.
23 Если вам понадобится создавать расширения для Python с помощью языка C, обратитесь к статье «Расширяем Python с помощью C или C++» (https://docs.python.org/3/extending/extending.html). Для получения более подробной информации см. главу 15 книги «Python Cookbook» (http://bit.ly/python-cookbook).
24 Сниппеты — это фрагменты кода, которые часто повторяются, вроде стилей CSS или определений классов. Вы можете использовать для них автозаполнение, если введете несколько символов, а затем нажмете клавишу Tab.
25 Просто откройте редактор, введя в командной строке vi (или vim) и нажав клавишу Enter, потом введите :help и нажмите Enter для прохождения обучения.
26 Для того чтобы найти домашний каталог в Windows, откройте Vim и введите команду :echo $HOME.
27 Нам нравится Реймонд Хеттингер. Если бы все писали код так, как он рекомендует, мир был бы гораздо лучше.
28 Electron — платформа для создания кросс-платформенных настольных приложений с помощью HTML, CSS и JavaScript.
29 https://github.com/Microso/PTVS/wiki/Features-Matrix.
30 Если вам больше нравится, используйте команду Set-ExecutionPolicy AllSigned.
31 POSIX расшифровывается как Portable Operating System Interface (портируемый интерфейс операционных систем). Включает набор стандартов IEEE, указывающих ОС ее поведение и интерфейс для простых команд оболочки, ввода/вывода, работы с потоками и для других сервисов и утилит. Большая часть дистрибутивов Linux и Unix совместима с POSIX, Darwin (операционная система, лежащая в основе Mac OS X и iOS), была совместима с версии Leopard (10.5). Фраза «система POSIX» означает систему, совместимую с POSIX.
32 Egg — это ZIP-архив с особой структурой. Эти архивы были заменены на архивы wheels в PEP 427 (https://www.python.org/dev/peps/pep-0427/). Были представлены популярной библиотекой упаковки Setuptools (сейчас библиотека по умолчанию), предлагающей полезный интерфейс для distutils (https://docs.python.org/3/library/distutils.html) из стандартной библиотеки Python. Вы можете прочесть об особенностях этих форматов в разделе Wheel vs Egg (https://packaging.python.org/en/latest/wheel_egg/) руководства Python Packaging User.
33 YAML (https://en.wikipedia.org/wiki/YAML) расшифровывается как YAML Ain’t Markup Language — «не просто еще один язык разметки».
34 Виртуальная машина — это приложение, которое эмулирует компьютерную систему путем имитации желаемого аппаратного обеспечения и предоставления требуемой операционной системы для компьютера-хоста.
35 Виртуальная среда внутри контейнера Docker изолирует вашу среду Python, сохраняя версию Python операционной системы, которая может понадобиться для ваших приложений. Поэтому прислушайтесь к нашему совету ничего не устанавливать с помощью pip (или чего-то еще) в системный каталог Python.
Часть 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. Для установки этой программы введите в терминале такую команду: $ 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)
Дзен Питона. Автор Тим Питерс
Красивое лучше, чем уродливое.
Явное лучше, чем неявное.
Простое лучше, чем сложное.
Сложное лучше, чем запутанное.
Одноуровневое лучше, чем вложенное.
Разреженное лучше, чем плотное.
Читаемость имеет значение.
Особые случаи не настолько особые, чтобы нарушать правила.
При этом практичность важнее безупречности.
Ошибки никогда не должны замалчиваться.
Если не замалчиваются явно.
Встретив двусмысленность, отбрось искушение угадать.
Должен существовать один — и желательно только один — очевидный способ сделать это.
Хотя он поначалу может быть и не очевиден, если вы не голландец.
Сейчас лучше, чем никогда.
Хотя никогда зачастую лучше, чем прямо сейчас.
Если реализацию сложно объяснить — идея плоха.
Если реализацию легко объяснить — идея, возможно, хороша.
Пространства имен — отличная штука! Будем делать их побольше!
Для того чтобы увидеть пример использования каждого из этих афоризмов, обратитесь к презентации Хантера Блэнкса (Hunter Blanks)
Общие советы
В этом разделе приводятся концепции, связанные со стилем (надеемся, вы с ними согласитесь). Зачастую они применимы и к другим языкам. Некоторые следуют непосредственно из «Дзена Питона», другие основаны на здравом смысле. Они подтверждают наш принцип работы: при написании кода Python выбирать наиболее очевидный способ его представления из имеющихся вариантов.
Явное лучше, чем неявное
В Python предпочтителен наиболее явный способ выражения:
Плохой код
Хороший код
def make_dict(*args):
x, y = args
return dict(**locals())
Поделиться книгой: