Путь Python. Черный пояс по разработке, масштабированию, тестированию и развертыванию E-Book
Джульен Данжу
Erhalten Sie Zugang zu diesem und mehr als 300000 Büchern ab EUR 5,99 monatlich.
- Herausgeber: Питер
- Kategorie: Wissenschaft und neue Technologien
- Sprache: Russisch
«Путь Python» позволяет отточить ваши профессиональные навыки и узнать как можно больше о возможностях самого популярного языка программирования. Эта книга написана для разработчиков и опытных программистов. Вы научитесь писать эффективный код, создавать лучшие программы за минимальное время и избегать распространенных ошибок. Пора познакомиться с многопоточными вычислениями и мемоизацией, получить советы экспертов в области дизайна API и баз данных, а также заглянуть внутрь Python, чтобы расширит понимание языка. Вам предстоит начать проект, поработать с версиями, организовать автоматическое тестирование и выбрать стиль программирования для конкретной задачи. Потом вы перейдете к изучению эффективного объявления функции, выбору подходящих структур данных и библиотек, созданию безотказных программ, пакетам и оптимизации программ на уровне байт-кода. Из этой книги вы узнаете как: • Создавать и использовать эффективные декораторы и методы • Работать в функциональном стиле • Расширять flake8 для работы с абстрактным синтаксическим деревом • Использовать динамический анализ производительности для определения узких мест • Работать с реляционными базами данных и эффективно управлять потоковыми данными с помощью PostgreSQL. Поднимите навыки владения Python с базового на высокий уровень. Получите советы экспертов и станьте профи!
Sie lesen das E-Book in den Legimi-Apps auf:
Seitenzahl: 270
Veröffentlichungsjahr: 2024
Das E-Book (TTS) können Sie hören im Abo „Legimi Premium” in Legimi-Apps auf:
Ähnliche
Переводчики П. Ковалёв, А. Логунов
Технический редактор А. Бульченко
Литературные редакторы О. Журбина, Е. Шубина
Корректоры Н. Викторова, М. Молчанова (Котова)
Верстка Л. Егорова
Джульен Данжу
Путь Python. Черный пояс по разработке, масштабированию, тестированию и развертыванию. — СПб.: Питер, 2021.
ISBN 978-5-4461-1308-8
© ООО Издательство "Питер", 2021
Все права защищены. Никакая часть данной книги не может быть воспроизведена в какой бы то ни было форме без письменного разрешения владельцев авторских прав.
Оглавление
Об авторе
Джульен Данжу занимается хакингом бесплатного ПО около двадцати лет, а программы на Python разрабатывает уже почти двенадцать лет. В настоящее время руководит проектной группой распределенной облачной платформы на основе OpenStack, которая владеет самой большой из существующих баз открытого кода Python, насчитывающей около двух с половиной миллионов строк кода. До разработки облачных сервисов Джульен занимался созданием менеджера окон и способствовал развитию многих проектов, например Debian и GNU Emacs.
О научном редакторе
Майк Дрисколл программирует на Python более десяти лет. Долгое время он писал о Python в блоге The Mouse vs. The Python1. Автор нескольких книг по Python: Python 101, Python Interviews и ReportLab: PDF Processingwith Python. Найти Майка можно в Twitter и на GitHub: @driscollis.
1http://www.blog.pythonlibrary.org/.
Благодарности
Написание первой книги потребовало значительных усилий. Оглядываясь назад, я понимаю, что даже не представлял себе, во что это выльется и насколько жизнеутверждающим будет завершение этого проекта.
Говорят, чтобы идти быстро, лучше идти одному, но если хочешь пройти далеко, надо идти с кем-то. Это уже четвертое издание книги, и я бы не прошел этот путь без людей, которые помогали мне. Это командная работа, и я хочу поблагодарить всех, кто принимал в ней участие.
Большинство людей, давших интервью для этой книги, уделили свое время и оказали мне доверие, и многому из того, что здесь написано, я обязан им: Дугу Хелману (Doug Hellman) за его советы о построении библиотек, Джошуа Харлоу (Joshua Harlow) за хорошее чувство юмора и знание распределенных систем, Кристофу де Вьенну (Christophe de Vienne) за его опыт в создании фреймворков, Виктору Стиннеру (Victor Stinner) за невероятные познания в CPython, Димитри Фонтейну (Dimitri Fontaine) за мудрость в базах данных, Роберту Коллинзу (Robert Collins) за всю грязную работу по тестированию, Нику Коглану (Nick Coghlan) за работу по приведению Python в лучшую форму и Полу Тальямонте (Paul Tagliamonte) за его хакерский дух.
Спасибо команде No Starch за то, что помогла поднять эту книгу на новый уровень, особенно Лиз Чедвик (Liz Chadwick) за редактирование, Лорел Чун (Laurel Chun) за то, что помогла не сбиться с пути, а также Майку Дрисколлу за научное редактирование.
Также хочу сказать спасибо всем сообществам ПО с открытым исходным кодом, которые делились знаниями и помогали мне расти. Особенная благодарность дружелюбному сообществу Python.
Введение
Если вы читаете эту книгу, то, скорее всего, уже работаете с Python. Возможно, вы изучали его онлайн, или на курсах, или с нуля. Как бы то ни было, вы хакнули способ его изучения. Именно так я и познакомился с Python до того, как десять лет назад начал работать над большими проектами с открытым исходным кодом.
Легко думать, что знаешь и разбираешься в Python, написав первую программу. Этот язык просто изучить. Тем не менее требуются годы, чтобы как следует овладеть им и развить глубокое понимание его преимуществ и недостатков.
Когда я начал программировать на Python, то создавал свои собственные библиотеки и приложения на уровне «домашних» проектов. Все изменилось, как только я стал работать вместе с сотнями разработчиков над проектами, которыми потом пользовались тысячи людей. Например, мой проект OpenStack состоит из девяти миллионов строк кода и постоянно нуждается в обслуживании, повышении эффективности и масштабировании под требования пользователей облачной платформы. Когда у вас проект такого уровня, тестирование или документирование требуют автоматизации, так как делать это вручную нереально.
Я думал, что хорошо изучил Python. Но мне пришлось узнать много нового, когда я начал работать с таким масштабным проектом. У меня появилась возможность познакомиться с лучшими умами Python и поучиться у них. Они научили меня многому: от общей архитектуры и принципов дизайна до всяческих полезных трюков. В этой книге я буду делиться всем этим с вами, чтобы вы могли создавать лучшие программы на языке Python — и создавать их эффективно!
Первая редакция книги The Hacker’s Guide to Python вышла в 2014 году. «Путь Python» — четвертая редакция этой книги с обновленным содержанием. Надеюсь, книга вам понравится!
Кому и зачем следует читать эту книгу
Книга рассчитана на разработчиков Python, которые хотят улучшить свои навыки.
В ней вы найдете методы и советы, которые помогут выжать максимум из Python и создавать программы, которые пройдут испытание временем. Если вы уже работаете над проектом, то можете сразу использовать описанные техники для улучшения кода. Если вы только начинаете проект, то сможете заложить фундамент программы, применяя лучшие практики.
Я познакомлю вас с некоторыми внутренними компонентами Python, чтобы вы понимали, как писать эффективный код. Вы сможете более глубоко разобраться во внутренней работе языка, что, в свою очередь, поможет увидеть проблемы или недостатки кода.
В книге также представлены проверенные на практике решения для таких проблем, как тестирование, перенос и масштабирование кода, приложений и библиотек Python. Это поможет избежать ошибок, допущенных другими программистами, а также найти стратегии, которые позволят в долгосрочной перспективе поддерживать ПО.
О книге
Необязательно читать эту книгу от начала и до конца — можно выбирать разделы, соответствующие вашим интересам или текущим проектам. В книге вы найдете большое разнообразие советов и практических решений. Вот краткий обзор содержания.
В главе 1 даны рекомендации по вопросам, касающимся запуска нового проекта, таким как структура, нумерация версий, настройка автоматического поиска ошибок и т.д. В конце главы вас ждет интервью с Джошуа Харлоу.
Глава 2 знакомит с модулями, библиотеками и фреймворками, а также рассказывает об их внутреннем устройстве. Вы найдете рекомендации по использованию модуля sys, поймете, как получить больше от менеджера пакетов pip, как выбрать лучший фреймворк, узнаете о применении стандартных и внешних библиотек. Кроме этого, в главе есть интервью с Дугом Хелманом.
В главе 3 даются советы по документированию проектов и управлению API по мере роста проекта, даже после публикации. В частности, вы узнаете, как использовать Sphinx для автоматизации документирования. Здесь же вы найдете интервью с Кристофом де Вьенном.
Глава 4 освещает давний вопрос о часовых поясах и то, как лучше всего работать с ними в программах, используя объекты datetime и tzinfo.
В главе 5 представлены рекомендации по распространению своего продукта среди пользователей. Вы узнаете о пакетировании, стандартах распространения, библиотеках distutilis и setuptools, а также о том, как легко обнаруживать динамические возможности в точках входа пакета. В конце представлено интервью с Ником Когланом.
В главе 6 даются советы об организации модульного тестирования с помощью лучших практик и автоматического тестирования с pytest. Мы рассмотрим использование виртуального окружения для изолирования тестов. Интервьюировать будем Роберта Коллинза.
В главе 7 подробно рассматриваются методы и декораторы. Это взгляд на функциональное программирование в Python, с советами о том, как и когда использовать декораторы и как создавать шаблоны проектирования для декораторов. Мы также разберемся со статическими, классовыми и абстрактными методами и тем, как их комбинировать.
В главе 8 содержатся трюки функционального программирования, которые вы можете реализовать в Python. В этой главе рассматриваются генераторы, списковое включение, функции функционального программирования и общие инструменты для их реализации, а также полезная библиотека functools.
Глава 9 проникает внутрь самого языка и рассматривает абстрактное синтаксическое дерево (АСД), которое является внутренней структурой Python. Мы также рассмотрим расширение flake8 для работы с АСД, позволяющее внедрить более сложные автоматические проверки в программы. Завершается глава интервью с Полом Тальямонте.
Глава 10 является руководством по оптимизации производительности с помощью использования соответствующих структур данных, эффективного определения функций и применения динамического анализа производительности для поиска узких мест в коде. Мы коснемся мемоизации и сократим расходы при копировании данных. Здесь вы найдете интервью с Виктором Стиннером.
Глава 11 затрагивает сложные вопросы многопоточности — когда стоит использовать многопоточность вместо многопроцессности, а также когда нужно применять событийно-ориентированную архитектуру вместо сервис-ориентированной для создания масштабируемых программ.
Глава 12 освещает вопрос реляционных баз данных. Мы рассмотрим их работу и использование PostgreSQL для эффективного управления потоковыми данными. В конце главы вас ждет интервью с Димитри Фонтейном.
В главе 13 предлагается целый набор рекомендаций по разным направлениям: как сделать код совместимым и с Python 2, и с Python 3, как создавать функциональный Lisp-подобный код, как использовать контекстные менеджеры и сокращать повторяющиеся действия с помощью библиотеки attr.
От издательства
Ваши замечания, предложения, вопросы отправляйте по адресу [email protected] (издательство «Питер», компьютерная редакция).
Мы будем рады узнать ваше мнение!
На веб-сайте издательства www.piter.com вы найдете подробную информацию о наших книгах.
1. Начало проекта
В первой главе мы рассмотрим этапы начала проекта, а также затронем вопросы, над которыми стоит подумать заранее: выбор версии языка Python, организация модулей, эффективная нумерация версий ПО, а также применение лучших практик создания кода с помощью автоматической проверки ошибок.
Версии Python
Прежде чем начать проект, необходимо решить, какую версию Python он будет поддерживать. Это не такое простое решение, как кажется на первый взгляд.
Ни для кого не секрет, что Python поддерживает несколько версий одновременно. У каждой новой версии интерпретатора есть техническая поддержка устранения ошибок сроком на восемнадцать месяцев и техническая поддержка безопасности сроком на пять лет. Например, релиз Python 3.7 состоялся 27 июня 2018 года и будет поддерживаться до выхода Python 3.82, что должно произойти в октябре 2019 года. Примерно в декабре 2019 года, когда произойдет последнее исправление ошибок Python 3.7, предполагается, что все перейдут на Python 3.8. Каждая новая версия Python предоставляет новые возможности и указывает на нерекомендуемые старые. Рисунок 1.1 показывает эту временную зависимость.
Кроме того, необходимо рассмотреть проблему использования Python 2 и Python 3. Специалистам, работающим с очень старыми системами, может понадобиться поддержка Python 2, так как Python 3 недоступен для таких систем. Однако по правилам хорошего тона забудьте о Python 2.
Рис. 1.1. Хронология выпуска Python
Вот как быстро определить, какая версия вам понадобится:
• Версии от 2.6 и ниже считаются устаревшими, поэтому я не рекомендую вообще задумываться об их технической поддержке. Если по каким-либо причинам вы хотите обеспечить техническую поддержку старых версий, то столкнетесь с кучей проблем, касающихся одновременной совместимости с Python 3.х. При работе со старыми системами вы все-таки можете столкнуться с Python 2.6, и если это произошло, то примите наши соболезнования.
• Версия 2.7 остается последней версией Python 2.х. Любая современная система в состоянии так или иначе работать с Python 3, и если вы не фанат древностей, то не стоит переживать о технической поддержке Python 2.7 в новых программах. Python 2.7 перестанут поддерживать после 2020 года, поэтому разрабатывать на его основе новое программное обеспечение — плохая идея.
• Последней версией развития Python 3 является Python 3.7, поэтому стоит сосредоточиться на нем. Но если ваша ОС поставляется с версией 3.6 (почти все операционные системы, кроме Windows, поставляются с 3.6 и ниже), убедитесь, что ваше приложение будет работать и с 3.6.
Техники создания программ, которые поддерживают и Python 2.х, и Python 3.х, будут рассмотрены в главе 13.
Обращаем ваше внимание, что эта книга была написана под Python 3.
План нового проекта
Начало нового проекта — та еще задача. Вы еще не знаете, как он будет структурирован, и поэтому могут возникнуть трудности с организацией файлов. Но как только вы поймете, как применить лучшие практики, то сможете определиться, с какой базовой структуры начать. В этом разделе я дам несколько советов, как планировать проект.
Что делать
Для начала рассмотрим структуру проекта: она должна быть как можно более простой. Осторожно используйте пакеты и иерархию: слишком глубокая иерархия затруднит перемещение, а слишком широкая будет неоправданно раздутой.
Избегайте распространенной ошибки по хранению модульных тестов вне директории с пакетом. Эти тесты определенно стоит включить в подпакет вашей программы, чтобы избежать их случайной автоматической установки в виде модуля верхнего уровня tests при использовании setuptools (или аналогичных библиотек разработки пакетов). Размещение их в подпакете гарантирует возможность установки и использования другими пакетами, что позволит остальным пользователям разрабатывать свои собственные модульные тесты.
На рис. 1.2 показана иерархия стандартного файла.
Рис. 1.2. Стандартная директория размещения модуля
Стандартным названием скрипта установки Python является setup.py, которое сопровождается setup.cfg, содержащим детали настройки процесса установки. При запуске setup.py установит модуль с помощью инструментов развертывания Python.
В файле README.rst (или README.txt, или с любым другим именем) можно разместить полезную информацию для пользователя. В директории docs должна быть документация о пакете в формате reStructuredText, который будет использоваться в Sphinx (см. главу 3).
В пакетах часто содержатся дополнительные сведения для работы, такие как изображения, сценарии командной оболочки и т.д. К сожалению, общепринятого стандарта для организации хранения этих данных нет, поэтому стоит расположить их внутри проекта наиболее близко к тому функционалу, который они обеспечивают. Например, шаблон веб-приложения должен находиться в папке templates, в корневой директории вашего пакета.
Также часто встречаются следующие директории верхнего уровня:
• etc — для типовых файлов конфигурации;
• tools — для сценариев командной оболочки и связанных инструментов;
• bin — для бинарных файлов, которые устанавливаются setup.py.
Что не делать
Я часто сталкиваюсь с таким недостатком планирования структуры проекта: некоторые разработчики присваивают имена файлам или модулям в зависимости от вида кода, который там хранится. Например, файлы могут называться functions.py или exceptions.py. Это плохой подход, не способствующий пониманию кода. Когда разработчик читает код, то ожидает, что в определенном файле будет заключена функциональная часть программы. Организация кода страдает от такого подхода, заставляя переходить между файлами без веской на то причины.
Организуйте свой код не на основе типов, а на основе ключевых характеристик.
Не создавайте директорию модуля, которая содержит только файл __init__.py, так как это излишнее вложение. Например, не стоит создавать директорию с именем hooks, в которой будет только один файл с именем hooks/__init__.py, достаточно создать просто hooks.py. Если вы создаете директорию, она должна содержать несколько файлов Python, принадлежащих одной категории. Построение глубокой иерархии без необходимости излишне.
Будьте аккуратны с кодом, который помещаете в __init__.py. Этот файл будет вызван и выполнен при загрузке модуля, содержащегося в директории. Расположение не тех элементов в __init__.py может привести к нежелательным результатам. Более того, файлы __init__.py должны быть пусты, если вы не знаете точно, что делаете. Не убирайте файлы __init__.py, иначе вы не сможете импортировать свой модуль: Python требует наличия файла __init__.py в директории, чтобы она считалась подмодулем.
Нумерация версий
Нумерация версий ПО необходима для того, чтобы пользователи могли найти самую последнюю из них. В каждом проекте нужно предусмотреть возможность прослеживать хронологию развития кода.
Существует множество способов организовать нумерацию версий. Однако PEP 440 представляет рекомендуемый к применению для каждого пакета или приложения формат нумерации, который позволит легко идентифицировать необходимую версию программы.
PEP 404 определяет следующий формат обычного выражения для нумерации версий:
N[.N]+[{a|b|c|rc}N][.postN][.devN]
Такой формат позволяет осуществлять стандартную нумерацию вида 1.2 или 1.2.3. Дополнительно можно выделить несколько нюансов:
• Версия 1.2 эквивалентна 1.2.0, а 1.3.4 эквивалентна 1.3.4.0 и т.д.
• Версии, соответствующие N[.N], считаются финальным релизом.
• Версии, в основе которых есть дата, например 2013.06.22, считаются недопустимыми. Средства автоматизации разработаны таким образом, чтобы распознавать запись формата РЕР 440. Система выдаст ошибку, если номер версии больше или равен 1980.
Могут применяться следующие форматы:
• N[.N]+aN (например, 1.2а1) означает релиз альфа-версии; такая версия может работать нестабильно и не обладать всем функционалом.
• N[.N]+bN (например, 2.3.1b2) означает бета-версию, которая уже обладает полным функционалом, но может работать нестабильно.
• N[.N]+cN или N[.N]+rcN (например, 0.4rc1) означает предрелизную версию. Это версия, которая может быть выпущена как финальный продукт, если в ней не будет обнаружено серьезных ошибок. Суффиксы rc и c имеют одинаковое значение, при их совместном использовании предполагается, что rc соответствует более свежей версии.
Помимо этого, применяются следующие суффиксы:
• Суффикс .postN (например, 1.4.post2) указывает на пострелиз. Пострелиз обычно применяется для устранения ошибок, возникших в ходе публикации, как, например, несоответствия документации. Не стоит использовать суффикс .postN при выпуске версии, устраняющей ошибки. Вместо этого стоит увеличить порядковый номер релиза.
• Суффикс .devN (например, 2.3.4.dev3) означает версию в разработке. Он указывает на предрелиз версии, на которую распространяется: например, 2.3.4.dev3 означает, что это третья версия в разработке релиза версии 2.3.4, следующая ранее альфы, беты, предрелизной или релизной версии. Такой суффикс сложен, поэтому его использование не приветствуется.
Эта схема применима для большинства случаев.
Примечание
Возможно, вы слышали о семантической нумерации со своими правилами. Этот подход частично пересекается с РЕР 440, но, к сожалению, эти подходы не полностью совместимы. Например, семантическая нумерация рекомендует схему для обозначения предрелизной версии, которая имеет вид 1.0.0-alpha+001, что не соответствует РЕР 440.
Многие распределенные системы контроля версий, такие как Git и Mercurial, генерируют номера версий с помощью хеширования (для Git смотрите git describe). К сожалению, эта схема несовместима со схемой РЕР 440: хешированные значения нельзя упорядочить.
Стиль кода и автоматические проверки
Стиль кода — это деликатный вопрос, но следует его обсудить, прежде чем изучать Python дальше. В отличие от многих языков программирования, в Python используются отступы для разделения блоков кода. Хотя это и отвечает на многолетний вопрос «Где разместить скобки?», но поднимает другой: «Где сделать отступы?».
Это был один из первых вопросов, поднятых в сообществе, и пользователи высказали свои предпочтения в РЕР 8: Руководстве по написанию кода на Python (https://www.python.org/dev/peps/pep-0008/).
Этот документ определяет стандарт написания кода на Python. Вот его краткое содержание:
• Используйте четыре пробела на каждый уровень отступа.
• Ограничьте длину строки максимум 79 символами.
• Отделяйте функции верхнего уровня и определения классов двумя пустыми строками.
• Кодируйте файлы с помощью ASCII или UTF-8.
• Каждый импорт, как правило, должен быть на отдельной строке. Импорты всегда помещаются в начале файла, сразу после комментариев к модулю и строк документации, и перед объявлением констант, а также группируются в следующем порядке: импорты из стандартной библиотеки, импорты сторонних библиотек, импорты модулей текущего проекта.
• Избегайте использования пробелов непосредственно внутри круглых, квадратных или фигурных скобок, а также перед запятыми.
• Пишите имена классов верблюжьим регистром (например, CamelCase), оканчивайте исключения словом Error (если, конечно, исключение действительно является ошибкой), имена функций пишите строчными буквами, а слова разделяйте символами подчеркивания (например, separated_by_underscore). Используйте нижнее подчеркивание в начале атрибутов и методов.
Следовать этим рекомендациям несложно, и они очень полезны. Большинство программистов Python придерживаются этих правил при написании кода.
Как бы то ни было, человеку свойственно ошибаться, и каждый раз просматривать свой код на соответствие рекомендациям РЕР 8 может быть затруднительно. К счастью, существует инструмент рер8 (его можно найти на https://pypi.org/project/pep8/), который может автоматически проверить любой файл в Python. Установите рер8 с помощью pip и применяйте его следующим образом:
$ pep8 hello.py
hello.py:4:1: E302 expected 2 blank lines, found 1
$ eсho$?
1
В примере я использовал рер8 в файле hello.py и получил вывод о строках и столбцах, не соответствующих РЕР 8, а также отчет о проблемах с кодом — в данном примере это строка 4 и столбец 1. Нарушения обязательных требований выводятся как ошибки (error), и коды ошибок начинаются на Е. Незначительные проблемы выводятся как предупреждения (warnings), а начинаются на W. Трехзначный код после буквы указывает на тип ошибки или предупреждения.
Первая цифра указывает на общую категорию ошибки: например, ошибка Е2 указывает на проблемы с пробелами, ошибка, начинающаяся на Е3 — на проблемы с пустыми строками, а предупреждение W6 — на использование устаревших функций. Все коды перечислены в документации рер8 (https://pep8.readthedocs.io/).
Инструменты для выявления несоответствия стиля
Сообщество ведет дебаты о необходимости проверки кода на соответствие РЕР 8, который не входит в набор стандартных возможностей. Но я советую постоянно таким способом проверять код. Этого легко добиться, если внедрить проверку в вашу систему непрерывной интеграции. Хотя этот подход и выглядит сложным, но обеспечивает поддержку принципов РЕР 8 на протяжении всего пути. В главе 6 мы узнаем, как можно интегрировать pep8 и tox для автоматизации этих проверок.
Большинство проектов с открытым исходным кодом обеспечивают соответствие РЕР 8 через автоматическую проверку. Введенная с начала проекта, она может расстроить новичков, но при этом обеспечит одинаковый стиль кода на протяжении всего проекта. Это очень важно для проекта любого уровня, потому что взгляды разработчиков могут не совпадать, например, по вопросу постановки пробелов. Вы знаете, что я имею в виду.
Можно настроить проверку так, чтобы игнорировать определенные ошибки и предупреждения, используя опцию –-ignore. Например:
$ pep8 --ignore=E3 hello.py
$ echo $?
0
Эта команда проигнорирует все ошибки Е3 внутри файла hello.py. Опция --ignore позволяет избегать тех рекомендаций РЕР 8, которым вы не хотите следовать. Использование инструмента рер8 на существующем коде позволит игнорировать определенные проблемы, чтобы сначала исправить только ошибки видимой категории, а затем переходить к другим.
Примечание
Если вы пишете код на языке С для Python (например, модуль), то изучите стандарт РЕР 7, содержащий необходимые рекомендации по стилю, которых стоит придерживаться.
Инструменты для выявления ошибок в коде
В Python есть инструменты для выявления ошибок в коде, а не ошибок стиля. Вот несколько полезных примеров:
• Pyflakes (https://launchpad.net/pyflakes/): расширяется через плагины.
• Pylint (https://pypi.org/project/pylint/): проверяет не только на наличие ошибок, но и на совместимость с РЕР 8; расширяется через плагины.
Эти инструменты проводят статический анализ — они передают код и анализируют его, а не исправляют ошибки по ходу разработки.
Если вы будете использовать Pyflakes, обратите внимание, что он не проверяет на соответствие РЕР 8, поэтому понадобится отдельный инструмент для этой задачи.
Проект flake8 (https://pypi.org/project/flake8/) уже сочетает pyflakes и pep8. У него есть и свои уникальные функции: например, он может пропускать проверку строк, содержащих #noqa, также расширяется через плагины.
Существует множество плагинов для flake8,которые используются как готовый продукт. Например, установка flake8-import-order (командой pip install flake8-import-order) расширит flake8 так, что он проверит расположение всех строк import вашего кода в алфавитном порядке.
В большинстве проектов с открытым исходным кодом flake8 используется повсеместно для проверки стиля кода. Некоторые большие проекты даже написали свои плагины для flake8, добавив проверки на такие ошибки, как неуместное использование except, совместимость Python2/3, стили импорта, опасное форматирование строк, проблемы с локализацией и пр.
Если вы начинаете новый проект, настоятельно рекомендую использовать один из этих инструментов автоматической проверки качества и стиля кода. Для существующего кода, который не проходил автоматическую проверку, хорошим решением будет прогнать его через один из инструментов, предварительно отключив все категории ошибок, кроме одной, и разобраться с этой категорией, прежде чем переходить к следующей.
Хотя ни один из этих инструментов не может полностью отвечать требованиям вашего проекта, flake8 это хороший способ улучшить качество и читабельности кода.
Примечание
Многие текстовые редакторы, включая известные GNU Emacs и vim, имеют доступные плагины (например Flycheck), которые могут запускать pep8 и flake8 прямо в коде и обеспечивать интерактивную подсветку любой части кода, которая не совпадает с рекомендациями РЕР 8. Это очень удобный способ устранять ошибки прямо в процессе написания кода.
Мы поговорим о расширении инструментария в главе 9, где воспользуемся собственным плагином для проверки правильности объявления метода.
Джошуа Харлоу о Python
Джошуа Харлоу — разработчик на Python. Был ведущим разработчиком в команде OpenStack в Yahoo! в период с 2012 по 2016 год и работал над GoDaddy. Джош автор нескольких библиотек для Python, в том числе Taskflow, automation и Zake.
Что побудило Вас программировать на Python?
Я начал программировать на Python 2.3 или 2.4 в 2004 году, когда проходил стажировку в IBM в Покипси, штат Нью-Йорк. Я уже не помню, чем конкретно там занимался, но это касалось wxPython и какого-то кода Python, который должен был автоматизировать их систему.
После стажировки я вернулся и продолжил обучение в Рочестерском технологическом институте, а потом получил работу в Yahoo!.
Там я работал в отделе главного инженера, где вместе с коллегами мы занимались решением задачи, какую облачную платформу с открытым исходным кодом использовать. Мы остановились на OpenStack, которая практически вся была написана на Python.
Что Вам нравится/не нравится в Python?
То, что мне нравится (неполный список):
• Он прост — новичкам легче начать работу с него, а опытным разработчикам — продолжить писать на нем.
• Проверка стиля. Возвращаться к ранее написанному коду — неотъемлемая часть разработки ПО, поэтому возможность поддерживать единообразие кода с помощью инструментов flake8, pep8 и Pylint является очень полезной.
• Возможность выбирать стиль программирования и подстраивать его под свои нужды.
То, что мне не нравится (неполный список):
• Сложный переход с Python 2 на 3 (в версии 3.6 большая часть этих проблем была решена).
• Лямбды слишком упрощенные и должны быть более эффективными.
• Отсутствие достойного установщика пакетов — pip. По моему мнению, здесь требуется доработка, хотя бы в области внедрения зависимостей.
• GIL — Global Interpreter Lock (Глобальная блокировка интерпретатора) и необходимость в ней. (Подробнее о GIL в главе 11.)
• Отсутствие встроенной поддержки многопоточности. В данный момент нужна поддержка явной модели asyncio.
• Раскол сообщества Python, которое главным образом существует вокруг CPython и PyPy (а также альтернатив).
Вы работаете над debtcollector. Это модуль Python для управления техническим долгом. Каково это — начинать новую библиотеку?
Упомянутая выше простота языка делает процесс создания и распространения библиотеки среди пользователей тривиальной задачей. Часть кода была взята из другой библиотеки, над которой я работаю (taskflow3), поэтому было несложно адаптировать и расширить код, так как не надо было беспокоиться, что API выйдет плохо спроектированным. Я очень рад, что люди (внутри сообщества OpenStack и вне его) нашли применение и оценили пользу этого проекта, и надеюсь, что библиотека вырастет и выявит больше нежелательных паттернов, которые применяются повсеместно в библиотеках и приложениях.
Чего, по-Вашему, не хватает Python?
Если бы в Python была JIT-компиляция, то он был бы производительнее. Большинство современных языков (таких как Rust, Node.js с движком Chrome V8 JavaScript и др.) обладают многими возможностями, реализованными в Python, а также имеют JIT-компиляцию. Если бы по умолчанию в CPython была JIT-компиляция, Python мог бы конкурировать с этими языками в плане производительности.
Кроме того, Python очень нуждается в наборе шаблонов параллельного проектирования с высокоуровневой концепцией, которая бы помогала приложениям работать эффективнее даже при масштабировании, а не ограничиваться низкоуровневым asyncio и паттернами многопоточного выполнения. Python-библиотека goless портирует некоторые концепции из Go, которые обеспечивают встроенную параллельную модель. Я считаю, что эти паттерны более высокого уровня должны быть доступны в стандартной библиотеке. Кроме этого, должна быть обеспечена их поддержка, чтобы разработчики могли свободно ими воспользоваться при необходимости. Без этого Python не может конкурировать с языками, в которых есть эти паттерны.
Продолжайте программировать и будьте счастливы!
2 25 февраля 2019 вышла предварительная версия Python 3.8.0a2. На момент выхода книги находится в разработке. — Здесь и далее примеч. ред.
3 Участие в проекте приветствуется. Переходите и участвуйте irc://chat.freenode.net/openstack-state-management.
