Python: кавычки в строках – рекомендации PEP 8 для Python
PEP 8 рекомендует использовать одинарные кавычки в строках Python, если внутри нет одинарных кавычек. Это повышает читаемость и поддерживается линтерами и форматерами.
В Python можно писать строковые литералы как в одинарных, так и в двойных кавычках. Есть ли какие‑то рекомендации по стилю или конвенции, которые советуют использовать один тип кавычек?
В Python выбор между одинарными ('...') и двойными ("...") кавычками для строковых литералов – это вопрос стиля, а не функциональности. Официальный гайд по стилю, PEP 8, рекомендует использовать одинарные кавычки, если строка не содержит одинарных кавычек, которые пришлось бы экранировать. Последовательное использование кавычек уменьшает шум diff, повышает читаемость и поддерживается многими линтерами и форматтерами.
Contents
- What does PEP 8 recommend?
- Why consistency matters in a codebase
- Choosing quotes based on content
- Common project practices and tooling
- Docstrings and f‑strings
- Summary and next steps
Что рекомендует PEP 8?
PEP 8, канонический гайд по стилю кода Python, утверждает, что строковые литералы могут быть ограничены как одинарными, так и двойными кавычками. Он явно советует:
«Предпочитайте одинарные кавычки вместо двойных, но используйте двойные, если строка содержит одинарные кавычки.»
Эта рекомендация призвана поддерживать согласованность кода и избегать лишнего экранирования. Она относится к обычным строковым литералам, но не к докстрингам и f‑строкам, которые рассматриваются отдельно.
Согласно документации Python о строковых литералах, язык сам рассматривает одинарные и двойные кавычки как эквивалентные; выбор – чисто стилистический.
Почему последовательность важна в кодовой базе
- Читаемость diff – Переключение с одинарных на двойные кавычки может вызвать огромный diff, даже если содержимое строки не изменилось, усложняя ревью кода.
- Линтинг и форматирование – Инструменты вроде flake8, pycodestyle и black могут автоматически применять выбранный стиль, уменьшая ручные проверки.
- Низкая когнитивная нагрузка – Разработчики могут сосредоточиться на логике, а не запоминать, какие кавычки использовать в каждой ситуации.
В больших кодовых базах несогласованное использование кавычек может вызвать конфликтов при слиянии, путаницу с правилами экранирования и ощущение небрежного стиля кодирования.
Выбор кавычек в зависимости от содержимого
| Условие | Предпочтительная кавычка | Причина |
|---|---|---|
Строка содержит одинарную кавычку (') |
Двойные кавычки | Избегает экранирования ("He said, 'Hello'.") |
Строка содержит двойные кавычки (") |
Одинарные кавычки | Избегает экранирования ('She said, "Hi"!') |
| Строка содержит обе | Тройные кавычки или экранирование | Обрабатывает многострочные или сложные литералы |
| Внутри нет кавычек | Одинарные кавычки (по умолчанию PEP 8) | Последовательность и минимальное экранирование |
# Предпочтительно по PEP 8
greeting = 'Hello, world!'
# Экранирование не требуется
question = "Who's there?"
# При обратном порядке экранирование было бы необходимо
# question = 'Who\'s there?'
Если строка содержит обе типы кавычек, обычно лучше использовать тройные кавычки ('''...''' или """..."""), особенно для многострочных строк или докстрингов.
Общие практики проектов и инструменты
-
Black – Непреклонный форматтер кода по умолчанию использует двойные кавычки для строковых литералов, но его можно настроить с помощью
--skip-string-normalizationили--string-normalization, чтобы соблюдать предпочтение PEP 8 к одинарным кавычкам.
Смотрите документацию Black. -
flake8 / pycodestyle – Эти линтеры применяют правила PEP 8, включая предпочтение кавычек. Их можно настроить в
setup.cfgили.flake8, чтобы соответствовать стилю проекта. -
EditorConfig – Некоторые команды используют настройки EditorConfig (
quote_style=single), чтобы принудительно применять кавычки на уровне редактора. -
Google Python Style Guide – Руководство Google повторяет PEP 8: «Предпочитайте одинарные кавычки, но используйте двойные, если в строке встречается одинарная кавычка.»
Команды проектов обычно определяют конвенцию на раннем этапе жизненного цикла репозитория и документируют её в STYLEGUIDE.md или CONTRIBUTING.md. Последовательность важна, даже если выбранный стиль отклоняется от дефолта PEP 8.
Докстринги и f‑строки
Хотя строковые литералы следуют предпочтению одинарных кавычек, у докстрингов есть своя конвенция:
- Докстринги – Тройные двойные кавычки (
"""docstring""") обязательны по PEP 257. Использование тройных одинарных кавычек ('''docstring''') технически допустимо, но не рекомендуется, поскольку затрудняет корректную обработку инструментами вроде Sphinx. - f‑строки – Интерполяция строк с
f\"...\"илиf'...'следует той же правилам кавычек, что и обычные строки. Предпочитайте одинарные кавычки, если выражение не содержит одинарной кавычки, требующей экранирования.
def greet(name: str) -> str:
"""Возвращает приветствие для *name*."""
return f'Hello, {name}!'
Итоги и дальнейшие шаги
- PEP 8 рекомендует использовать одинарные кавычки для строковых литералов, если в строке не встречается одинарная кавычка.
- Последовательность в проекте снижает шум при слиянии и повышает читаемость.
- Используйте поддержку инструментов (Black, flake8, EditorConfig), чтобы принудительно применять выбранный стиль.
- Докстринги должны использовать тройные двойные кавычки согласно PEP 257, независимо от правила одинарных/двойных кавычек для обычных строк.
- Если строка содержит обе типы кавычек, рассмотрите тройные кавычки или правильное экранирование.
Принятие чёткой, задокументированной конвенции кавычек и использование автоматических форматтеров поможет поддерживать чистый, читаемый код по мере роста проекта.