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

46 Должны признать: хотя в PEP 3101 (https://www.python.org/dev/peps/pep-3101/) форматирование с использованием знака % (%s, %d, %f) считается устаревшим, большинство разработчиков старой школы все еще используют его. В PEP 460 (https://www.python.org/dev/peps/pep-0460/) был представлен такой же метод форматирования байтов или объектов bytearray.

47 Обратите внимание, что метод unittest.TestCase.tearDown не будет запущен, если в коде есть ошибки. Это может удивить вас, если вы использовали функциональность unit­test.mock для того, чтобы изменить реальное поведение кода. В Python 3.1 был добавлен метод unittest.TestCase.addCleanup(). Он помещает функцию очистки и ее аргументы в стек, и эта функция будет вызвана либо после метода unittest.Test­Case.tearDown(), либо в любом случае независимо от того, был ли вызван метод tearDown(). Для получения более подробной информации обратитесь к документации метода unittest.Test­Ca­se.add­Cleanup() (см. http://docs.python.org/3/library/unit­test.html#unit­test.TestCa­se.add­Cleanup).

48 Для тех, кому интересно: развернулась дискуссия о введении поддержки (https://bitbuc­ket.org/pypa/pypi/issues/148/support-markdown-for-readmes) в файлах README в PyPI.

49 Вы можете встретить и другие инструменты вроде Pycco, Ronn, Epydoc (больше не поддерживается) и MkDocs. Практически все используют Sphinx, мы также рекомендуем выбрать его.

50 На момент написания книги они находились под лицензией Academic Free License v.2.1 или Apache License, Version 2.0. Полное описание того, как это работает, вы можете найти на странице https://www.python.org/psf/contrib/.

51 Все лицензии, описанные здесь, одобрены OSI, вы можете узнать о них на главной странице OSI по адресу https://opensource.org/licenses.

52 Аббревиатура tl;dr означает «Too long; didn’t read» («Слишком длинно, не читал») и, скорее всего, существовала как сокращение для редакторов, пока не стала популярной в Интернете.

5. Читаем отличный код

Программисты читают много кода. И один из основных принципов, лежащих в основе дизайна Python, — читаемость. Ключ к тому, чтобы стать хорошим программистом, — читать и понимать отличный код. Такой код обычно следует принципам, которые мы перечисляли в разделе «Стиль кода» в начале главы 4, и его предназначение легко понять.

В этой главе приводятся выдержки из наиболее читаемых проектов Python, которые иллюстрируют темы, рассмотренные в главе 4. По мере их описания мы также поделимся приемами чтения кода53.

Перед вами список проектов, которые продемонстрированы в этой главе, они приведены в том порядке, в котором появляются:

• HowDoI (https://github.com/gleitz/howdoi) — консольное приложение, которое ищет в Интернете ответы на вопросы, связанные с программированием; написано на Python; • Diamond (https://github.com/python-diamond/Diamond) — демон Python54, который собирает метрики и публикует их на Graphite или других бэкендах. Может собирать метрики для процессора, памяти, сети, ввода-вывода, загрузки и дисков. Предоставляет API для реализации пользовательских сборщиков метрик из практически любого источника; • Tabli (https://github.com/kennethreitz/tablib) — независимая от формата библиотека, позволяющая работать с таблицами данных; • Requests (https://github.com/kennethreitz/requests) — библиотека для протокола передачи гипертекста (HyperText Transfer Protocol, HTTP) для людей (90 % из нас хотят иметь HTTP-клиент, который автоматически выполняет авторизацию и соответствует многим стандартам (https://www.w3.org/Protocols/) для выполнения таких заданий, как многокомпонентная загрузка файла с помощью единственного вызова функции); • Werkzeug (https://github.com/mitsuhiko/werkzeug) изначально был коллекцией различных утилит для приложений стандарта Web Service Gateway Interface (WSGI), а теперь стал одним из наиболее мощных вспомогательных модулей WSGI; • Flask (https://github.com/mitsuhiko/flask) — микрофреймворк для Python, основанный на Werkzeug и Jinja2. Подойдет для быстрого создания веб-страниц.

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

Типичные функции

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