Введение

В «Дзене Python» (PEP 20) есть знаменитая строчка: «Должен быть один — и, желательно, только один — очевидный способ сделать это». Однако, когда дело доходит до форматирования строк, Python, кажется, сам нарушает свои же заповеди.

Оператор %, метод .format(), f-строки, класс Template... За годы развития языка наслоилось столько инструментов, что даже опытные разработчики иногда пишут код «по инерции», используя конструкции десятилетней давности там, где можно сделать проще и быстрее. Новички же часто путаются в синтаксисе, не понимая, почему в одном туториале используют %s, а в другом — фигурные скобки.

Но форматирование — это не просто вопрос вкуса или «сахара». Это вопрос читаемости кода, производительности и безопасности.

В этой статье мы пройдем путь эволюции работы со строками в Python: от «древнего» C-style форматирования до современных f-строк. Разберем, что скрывается «под капотом» мини-языка форматирования (Format Specification Mini-Language), замерим скорость разных подходов и выясним, в каких редких случаях новомодные f-строки — это плохая идея.

2. Эпоха динозавров: C-style форматирование (%)

Исторически первым способом форматирования в Python был оператор %. Если вы пришли из языка C (или любого другого, наследующего его синтаксис), вы сразу узнаете старый добрый printf.

Суть метода проста: строка выступает в роли шаблона, где с помощью спецификаторов типа %s (строка), %d (целое число) или %f (float) мы размечаем места для подстановки переменных.

username = "Admin"
login_count = 42

# Простой пример
print("Пользователь: %s, входов: %d" % (username, login_count))
# Вывод: Пользователь: Admin, входов: 42

Казалось бы, всё работает. Вы даже можете управлять точностью чисел с плавающей точкой, что было большим плюсом в ранних версиях:

pi = 3.14159
print("Число Пи: %.2f" % pi)
# Вывод: Число Пи: 3.14

Почему мы от этого уходим?

Несмотря на привычность для сишников, этот стиль быстро показывает свои зубы, как только проект вырастает за пределы «Hello World».

1. Проблема читаемости (Verbosity)
Когда переменных становится много, строка превращается в месиво. Вам приходится постоянно бегать глазами из начала строки (где плейсхолдеры) в конец (где переменные), чтобы понять, что куда подставляется. Ошибка в порядке аргументов в кортеже гарантирует, что User_ID окажется на месте Balance, а Balance — на месте имени.

# Попробуйте сходу понять, не перепутаны ли аргументы?
log_msg = "Error in module %s: process %d failed at %s with code %d" % (mod_name, proc_id, timestamp, err_code)

2. «Ловушка кортежа» (Tuple quirks)
Оператор % ведет себя по-разному в зависимости от того, сколько аргументов вы передаете и какого они типа. Это классический источник багов.

Если вы передаете один аргумент, оператор ожидает просто значение. Если несколько — обязательно нужен кортеж. Но что, если ваш единственный аргумент сам по себе является кортежем?

data = (1, 2, 3)

# Мы хотим вывести: "Data: (1, 2, 3)"
print("Data: %s" % data)

Результат: TypeError: not all arguments converted during string formatting.
Python пытается распаковать data и найти внутри строки три плейсхолдера %s, а находит только один. Чтобы это починить, приходится писать уродливую конструкцию — кортеж из одного элемента, который содержит кортеж:

print("Data: %s" % (data,))

Вердикт:
Форматирование через % всё еще валидно и поддерживается (его не выпилят из языка, чтобы не сломать миллионы строк легаси). Однако в новом коде его использование считается моветоном. Единственное исключение — модуль logging, но об этом мы поговорим чуть позже.

Для всего остального Python придумал кое-что получше.

3. Попытка навести порядок: str.format()

С выходом Python 3.0 (и бэкпортированием в 2.6) разработчики решили кардинально переосмыслить подход к строкам. Новый метод str.format() был призван стать тем самым «единственным очевидным способом», заменив устаревший оператор %.

Синтаксис сместился от C-стиля к использованию фигурных скобок {}. Главное идеологическое изменение: теперь форматирование — это метод объекта строки, а не бинарная операция.

# Базовый пример
print("Привет, {}!".format("Хабр"))

# Больше не нужно думать о типах (%s vs %d) — метод сам вызывает __format__ у объекта
print("Координаты: {}, {}".format(55.75, 37.61))

В чем сила метода?

.format() принес несколько киллер-фич, которые заставили многих вздохнуть с облегчением.

1. Управление индексами
Вы больше не обязаны передавать аргументы в том же порядке, в котором они идут в строке. Более того, один и тот же аргумент можно использовать несколько раз без дублирования в вызове метода.

# Бонд. Джеймс Бонд.
s = "{1}, {0} {1}".format("Джеймс", "Бонд")
# Вывод: Бонд, Джеймс Бонд

2. Именованные аргументы (Читаемость)
Это решило главную проблему %-форматирования. Теперь можно явно указывать, какая переменная куда подставляется. Код стал самодокументируемым.

template = "Сервер {host} (порт {port}) недоступен."
print(template.format(host="192.168.0.1", port=8080))

3. Доступ к атрибутам и элементам
Внутри фигурных скобок можно обращаться к полям объектов или ключам словарей (обратите внимание: кавычки для ключей внутри {} не нужны).

class User:
    def __init__(self, name):
        self.name = name

u = User("admin")
print("Логин: {0.name}".format(u)) 

4. Распаковка словарей (**kwargs)
Пожалуй, самая мощная фича этой эпохи. Если у вас есть словарь с конфигурацией или данными из БД, вы можете просто «распаковать» его внутрь строки.

config = {"env": "production", "version": "1.0.2", "debug": False}

# Очень удобно для шаблонизации
log = "Environment: {env}, Version: {version}".format(**config)

Но почему мы не остановились на этом?

Казалось бы, идеал достигнут. Но со временем вскрылся главный недостаток .format() — его многословность.

Логика формирования строки разорвана: шаблон находится слева, а данные — справа, часто на другой строке или вообще за пределами видимости экрана. Если вы хотите вывести значение переменной user_name, вам приходится писать её имя дважды:

# Принцип DRY (Don't Repeat Yourself) вышел из чата
print("Hello, {user_name}".format(user_name=user_name))

Этот синтаксический шум утомлял разработчиков, особенно в Perl- или PHP-подобных скриптах с множеством вставок. Сообщество требовало лаконичности. И в Python 3.6 их мольбы были услышаны.

4. Современный стандарт: F-строки (Python 3.6+)

В 2016 году с выходом Python 3.6 и принятием PEP 498 жизнь питонистов разделилась на «до» и «после». Появились «Formatted String Literals», или просто f-строки.

Идея была радикальной: убрать вызов метода .format() и позволить встраивать выражения Python прямо внутри строковых литералов. Достаточно добавить префикс f перед кавычками.

name = "Хабр"
rating = 100500

# Было:
# print("Портал {0} имеет рейтинг {1}".format(name, rating))

# Стало:
print(f"Портал {name} имеет рейтинг {rating}")

Это не просто синтаксический сахар

Главное отличие f-строк от .format() в том, что содержимое фигурных скобок {} — это не просто ключи для подстановки, а полноценные Python-выражения, которые вычисляются во время выполнения (runtime).

Вы можете делать арифметику, вызывать функции и методы прямо внутри строки:

import math

radius = 5
# Вычисления прямо в строке
print(f"Площадь круга: {math.pi * radius ** 2}")

name = "python"
# Вызов методов
print(f"Заголовок: {name.upper()}")

Секретное оружие отладки (Python 3.8+)

Если вы до сих пор пишете print("var = ", var) для отладки, у меня для вас хорошие новости. Начиная с Python 3.8, в f-строках появился спецификатор =, который автоматически разворачивает выражение в текст имя_переменной = значение.

user_id = 42
apikey = "xhj7-9912"

# Самодокументируемая строка
print(f"{user_id=}, {apikey=}")
# Вывод: user_id=42, apikey='xhj7-9912'

Это экономит огромное количество времени при поиске багов и просмотре логов.

Нюансы, о которых забывают

Кажется, что f-строки решили все проблемы. Синтаксис чистый, работает быстро (да, f-строки быстрее, чем % и .format(), так как парсятся на этапе компиляции байт-кода).

Однако, хотя сам механизм подстановки стал интуитивным, правила форматирования значений (сколько знаков после запятой? как выровнять текст по центру? как вывести дату в ISO формате?) остались прежними и часто вызывают ступор. Новички часто гуглят каждый отдельный случай (python format float 2 decimal places), вместо того чтобы один раз разобраться в спецификации Mini-Language.

Если вы хотите не просто читать теорию, а набить руку на реальных задачах и тестах по всем методам (от старого % до продвинутых f-строк), рекомендую пройти бесплатный интерактивный курс по форматированию строк.

Там эти нюансы (выравнивание, типизация, вложенные f-строки) разбираются последовательно, с автопроверкой кода. Это помогает закрепить материал и перестать «плавать» в синтаксисе, когда нужно вывести красивую табличку в консоль.

5. Магия Mini-Language (Спецификаторы)

Многие останавливаются на том, что просто вставляют переменную в строку: f"{value}". Но настоящая мощь Python скрывается за двоеточием — : .

Именно после него начинается Format Specification Mini-Language. Это специальный синтаксис, который позволяет управлять представлением данных без написания лишнего кода (вроде round(), rjust() или ручного перевода в бинарный вид).

Общая структура выглядит так:
{ [имя_переменной] : [заполнитель][выравнивание][ширина][.точность][тип] }

Звучит страшно? Давайте разберем самые полезные кейсы.

1. Числа: деньги, проценты и разделители

Забудьте про round(num, 2). Форматирование чисел должно происходить в момент вывода, а не изменения данных.

price = 1234.56789
percent = 0.8912

# Классика: 2 знака после запятой (округление включено)
print(f"Цена: {price:.2f}")  
# -> Цена: 1234.57

# Проценты: умножает на 100 и добавляет знак %
print(f"Загрузка: {percent:.1%}") 
# -> Загрузка: 89.1%

# Финансовый формат: разделитель тысяч (запятая или подчеркивание)
big_money = 1000000000
print(f"Бюджет: ${big_money:_}") 
# -> Бюджет: $1_000_000_000

2. Выравнивание и ASCII-арт

Если вы пишете CLI-утилиты, логи или просто хотите вывести красивую таблицу в консоль, вам не нужно считать пробелы вручную.

• < — по левому краю (стандарт для строк).

• > — по правому краю (стандарт для чисел).

• ^ — по центру.

Самое приятное: перед знаком выравнивания можно указать символ-заполнитель.

title = "MENU"

# Центрируем текст в поле шириной 20 символов, заполняя пустоту знаком "="
print(f"{title:=^20}")
# -> ========MENU========

# Удобно для создания таблиц
print(f"{'Item':<10} | {'Qty':>5} | {'Price':>8}")
print(f"{'Apple':<10} | {5:>5} | {120.00:>8.2f}")
# -> Item       |   Qty |    Price
# -> Apple      |     5 |   120.00

3. Работа с системами счисления

Нужно вывести байтовое представление числа или HEX-код цвета? Функции bin() и hex() добавляют префиксы 0b и 0x, которые часто приходится обрезать. F-строки делают это изящнее.

value = 255

# b - binary, x - hex (X - uppercase HEX), o - octal
print(f"Bin: {value:08b}") # 8 бит, с ведущими нулями
# -> Bin: 11111111

print(f"Hex: {value:x}")   # просто число
# -> Hex: ff

# Модификатор # добавляет префикс, если он всё-таки нужен
print(f"Hex: {value:#x}")
# -> Hex: 0xff

4. Даты без strftime

Мало кто знает, но объекты datetime поддерживают протокол форматирования напрямую. Вам не нужно вызывать метод .strftime(), вы можете писать форматную строку прямо внутри фигурных скобок.

from datetime import datetime

now = datetime.now()

# Было:
# print(f"Date: {now.strftime('%Y-%m-%d %H:%M')}")

# Стало (чище и читаемее):
print(f"Date: {now:%Y-%m-%d %H:%M}")
# -> Date: 2023-10-05 14:30

5. Вложенные f-строки

Спецификаторы тоже могут быть динамическими! Вы можете вложить одну f-строку в другую (звучит как начало фильма Нолана, но это работает).

import math
width = 10
precision = 4
val = math.pi

# Мы передаем ширину и точность через переменные
print(f"Pi: {val:{width}.{precision}f}")
# -> Pi:     3.1416

Mini-language превращает рутинную работу со строками в декларативное описание «как это должно выглядеть», оставляя код чистым.

6. Сравнение производительности и Edge Cases

Когда f-строки только появились, скептики говорили: «Зачем нам еще один способ, если есть .format()?». Главным аргументом (помимо читаемости) стала скорость.

В отличие от .format(), который является вызовом метода во время выполнения, и %, который требует проверки типов, f-строки — это часть грамматики языка. Интерпретатор парсит их на этапе компиляции в байт-код и оптимизирует сборку строки.

Давайте проверим это на практике с помощью модуля timeit.

Бенчмарк

Мы будем формировать простую строку 1 миллион раз.

import timeit

setup = """
name = "Habr"
age = 18
"""

# Тест 1: Старый стиль (%)
t1 = timeit.timeit('s = "Hello %s, you are %d" % (name, age)', setup=setup, number=1000000)

# Тест 2: str.format()
t2 = timeit.timeit('s = "Hello {}, you are {}".format(name, age)', setup=setup, number=1000000)

# Тест 3: F-строки
t3 = timeit.timeit('s = f"Hello {name}, you are {age}"', setup=setup, number=1000000)

print(f"Old style (%):  {t1:.4f} sec")
print(f"str.format():   {t2:.4f} sec")
print(f"f-strings:      {t3:.4f} sec")

Типичный результат (Python 3.11 на M1):

Old style (%):  0.1842 sec
str.format():   0.2451 sec
f-strings:      0.1120 sec

Вывод: F-строки работают почти в 2 раза быстрее, чем .format(), и ощутимо быстрее старого стиля. В высоконагруженных циклах это может иметь значение. Но всегда ли их стоит использовать?

Нет. Есть случаи, где f-строки — это ошибка.

Edge Case #1: Логирование (Logging)

Это самая частая ошибка даже у мидл-разработчиков. Стандартный модуль logging в Python был написан очень давно и использует «ленивую» интерполяцию.

Плохо:

import logging
# F-строка вычисляется НЕМЕДЛЕННО, до передачи в функцию
logging.debug(f"Сложный расчет: {heavy_computation()}")

Если у вас уровень логирования выставлен на INFO или WARNING, то сообщение debug не должно попасть в лог. Однако, так как вы использовали f-строку, функция heavy_computation() всё равно выполнится, чтобы сформировать строку, которую логгер затем просто выбросит. Вы тратите CPU впустую.

Хорошо:

# Логгер сам вызовет форматирование (используя %-стиль), ТОЛЬКО если это нужно
logging.debug("Сложный расчет: %s", heavy_computation)

Примечание: это касается только передачи тяжелых функций или объектов. Если вы просто выводите переменную, разница в производительности пренебрежимо мала, но правила хорошего тона рекомендуют использовать нативный стиль логгера.

Edge Case #2: Безопасность (SQL Injection)

Никогда, ни при каких обстоятельствах не используйте f-строки для формирования SQL-запросов.

Катастрофа:

user_input = "' OR '1'='1"
# Взлом базы данных за 3 секунды
query = f"SELECT * FROM users WHERE name = '{user_input}'"

Решение:
Используйте параметризованные запросы вашей библиотеки (psycopg2, sqlite3 и т.д.).

cursor.execute("SELECT * FROM users WHERE name = ?", (user_input,))

Так же еще появились t-строки которые решают данную проблему.

Edge Case #3: Словари и кавычки (до Python 3.12)

До недавнего времени использование кавычек внутри f-строк было болью. Если вы хотели обратиться к ключу словаря, вам приходилось чередовать одинарные и двойные кавычки.

data = {"key": "value"}

# SyntaxError в Python < 3.12, если снаружи и внутри одни и те же кавычки
# print(f"Item: {data["key"]}") 

# Приходилось делать так:
print(f"Item: {data['key']}")

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

7. Заключение

История форматирования строк в Python — это отличный пример того, как язык развивается в сторону удобства человека, а не машины. Мы прошли путь от жесткого C-style наследия к элегантным и быстрым f-строкам.

Краткая шпаргалка (Rule of Thumb) для современного питониста:

1. По умолчанию используйте f-строки. Это стандарт де-факто для Python 3.6+. Они быстрее, чище и читаемее.

2. Используйте .format(), если строка шаблона существует отдельно от данных (например, загружается из конфига или базы данных) или если вам нужна совместимость с очень старыми версиями Python.

3. Используйте % (или стиль .format) только в модуле logging для отложенной интерполяции, чтобы не нагружать процессор лишней работой.

4. Никогда не используйте форматирование строк для SQL-запросов. Это прямая дорога к SQL-инъекциям.

В конечном итоге, выбор инструмента должен зависеть от читаемости. Код пишется один раз, а читается десятки. Используйте мощь Mini-Language, чтобы убрать лишнюю логику из кода, но не злоупотребляйте вложенными конструкциями, если они заставляют коллег (или вас через полгода) морщить лоб.

Пишите код так, чтобы он был понятен. Ведь, как гласит всё тот же Zen of Python: Readability counts.

---

P.S. Если статья была полезной, не забудьт�� прогнать свои старые проекты через линтеры — возможно, там накопилось много мест, которые можно ускорить и упростить одной лишь заменой .format() на f"".