В Python строки неизменяемы и это может удивить новичков. Попытка изменить строку вызовет ошибку:
>>>> s = "I'm not mutable"
>>>> s[1:7] = " am"
>Traceback (most recent call last):
>File "", line 1, in
>TypeError: 'str' object does not support item assignment
Это означает, что при создании строки по частям гораздо эффективнее собрать все части в список, поскольку его можно изменять, а затем объединить их. Кроме того, в Python предусмотрены списковые включения, которые предоставляют простой синтаксис для итерирования по входным данным для создания списка. В табл. 4.3 приведены способы создания строки из итерабельного объекта.
Таблица 4.3. Способы конкатенации строки
| Плохой | Хороший | Лучший |
|---|
>>>> s = "" | >>>> s = [] | >>>> r = (97, 98, 99) |
>>>> for c in (97, 98, 98): | >>>> for c in (97, 98, 99): | >>>> s = [unichr(c) for |
>… ····s += unichr(c) | >… ····s.append(unichr(c)) | >····c in r] |
>… | >… | >>>> print("".join(s)) |
>>>> print(s) | >>>> print("".join(s)) | >abc |
>abc | >abc | |
На главной странице Python (https://www.python.org/doc/essays/list2str/) вы можете найти обсуждение подобной оптимизации.
Наконец, если количество элементов конкатенации известно, добавить строку будет проще (и очевиднее), чем создавать список элементов только для того, чтобы вызвать функцию "".join().
Все следующие варианты форматирования для определения переменной cheese делают одно и то же[46]:
>>>> 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 в случае конфликтов), могут ограничить зависимости набором рабочих версий.
