Таня Шлюссер - Автостопом по Python

Наконец, если количество элементов конкатенации известно, добавить строку будет проще (и очевиднее), чем создавать список элементов только для того, чтобы вызвать функцию "".join().

Все следующие варианты форматирования для определения переменной cheese делают одно и то же [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. :

>>> adj = "Red"

>>> noun = "Leicester"

>>>

>>> cheese = "%s %s" % (adj, noun) # Этот стиль устарел (PEP 3101)

>>> cheese = "{} {}".format(adj, noun) # Возможно начиная с Python 3.1

>>> cheese = "{0} {1}".format(adj, noun) # Числа можно использовать повторно

>>> cheese = "{adj} {noun}".format(adj=adj, noun=noun) # Этот стиль — лучший

>>> print(cheese)

Red Leicester

Пакет, который использует зависимости, получаемые от третьей стороны , содержит внешние зависимости (сторонние библиотеки) внутри своего исходного кода, зачастую внутри каталога с именем vendor или packages. По адресу http://bit.ly/on-vendorizingвы можете прочесть весьма полезную статью, в которой перечисляются основные причины, почему владелец пакета может воспользоваться зависимостями третьей стороны (в основном для того, чтобы избежать проблем с совместимостью), а также рассматриваются альтернативные подходы.

Однако можно достичь консенсуса: почти во всех случаях лучше всего держать зависимости отдельно друг от друга, поскольку это добавляет ненужное содержимое (зачастую мегабайты дополнительного кода) в репозиторий. Виртуальные среды, использованные в сочетании с файлами setup.py (предпочтительно, особенно если пакет является библиотекой) или requirements.txt (при использовании переопределит зависимости в файле setup.py в случае конфликтов), могут ограничить зависимости набором рабочих версий.

Если этих вариантов недостаточно, можно связаться с владельцем зависимости, чтобы решить проблему, обновив его пакет (например, ваша библиотека может зависеть от выходящего релиза его пакета или вам нужна новая функциональность). Эти изменения, скорее всего, пойдут на пользу всему сообществу. Однако здесь имеется и подводный камень: если вы отправите запрос на включение больших изменений, вам, возможно, придется поддерживать эти изменения по мере появления дальнейших предложений и запросов (по этой причине в проектах Tablib и Requests несколько зависимостей получены от третьей стороны). По мере полного перехода сообщества на Python 3 мы надеемся, что проблемных областей станет меньше.

Тестировать код очень важно. Ведь люди будут использовать только такой проект, который на самом деле работает.

Модули doctest и unittest впервые появились в версии Python 2.1 (выпущена в 2001 году), поддерживая разработку через тестирование (test-driven development, TDD): разработчик сначала пишет тесты, которые определяют основную задачу и узкие места функции, а затем — функцию, которая проходит эти тесты. С тех пор TDD стали чаще использовать в бизнес-проектах и проектах с открытым исходным кодом — практиковаться в написании кода теста и параллельно самой функции довольно полезно. Если пользоваться этим методом с умом, он поможет вам четко определить предназначение своего кода и создать развернутую модульную структуру.

Тест — это самый объемный фрагмент кода, который автостопщик может написать. Приведем несколько советов.

Тестируйте что-то одно за раз.Юнит-тест должен концентрироваться на небольшом фрагменте функциональности и доказывать, что все работает, как требуется.

Независимость императивна.Каждый юнит-тест должен быть полностью независимым: его можно запустить как отдельно, так и внутри набора тестов без учета того, в каком порядке они вызываются. Из этого правила следует, что для каждого теста нужно загрузить свежий набор данных, а после его выполнения провести очистку (обычно с помощью методов setUp() и tearDown()).

Точность лучше простоты.Используйте длинные описательные имена для функций теста. Это правило отличается от правила для рабочего кода, где предпочительны короткие имена. Причина в том, что функции никогда не вызываются явно. В рабочем коде допускается использование имен square() или даже sqr(), но в коде теста у вас должны быть имена вроде test_square_of_number_2() или test_square_negative_number(). Эти имена функций будут выведены, когда тест даст сбой, они должны быть максимально описательными.