assert в Python: проверки для разработчика и AssertionError

До сих пор ловили чужие ошибки — те, что бросает Python или чужой код. У программиста есть и собственный инструмент заявлений: assert. Он не обрабатывает сбои, а проверяет договорённости: делитель не ноль, список не пуст, переменная инициализирована. Проваленная договорённость — это AssertionError, отдельный тип из иерархии урока 9. Разбираемся, как писать проверки, что происходит при провале и почему у assert есть репутация ненадёжного.

Как пишется assert

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

def divide(a, b):
    assert b != 0, 'делитель не должен быть нулём'
    return a / b

print(divide(10, 2))
print('программа дошла до конца')

5.0
программа дошла до конца

Условие b != 0 оказалось истинным — и assert сработал как комментарий: один раз прочитан и забыт. Сообщение после запятой — необязательная, но важная часть: без него AssertionError молчит, и из падения не понять, какая именно договорённость нарушена.

Что происходит при провале

Проваленная проверка — обычное исключение: программа без обработки падает, traceback из урока 1 показывает строку assert и сообщение. Вот что случится, если позвать ту же функцию с нулём:

# assert упадёт: делитель нулевой
divide(10, 0)

AssertionError — полноценное исключение: его можно поймать. В песочнице это и обязательное правило — попробуем провал нарочно и посмотрим на сообщение:

def divide(a, b):
    assert b != 0, 'делитель не должен быть нулём'
    return a / b

try:
    divide(10, 0)
except AssertionError as e:
    print('проверка провалена:', e)
print('программа продолжает работу')

проверка провалена: делитель не должен быть нулём
программа продолжает работу

Механика та же, что у любого except из урока 2, — но ловить AssertionError в рабочем коде обычно не надо. Проверка провалилась — значит, сломана договорённость вашего же кода: это баг, и правильная реакция — чинить код, а не глотать сигнал. У assert есть коварная особенность, из-за которой его вовсе можно не считать надёжным инструментом.

Флаг -O: проверки исчезают

assert-ы живут только в обычном режиме. Запуск python -O script.py включает оптимизацию, и Python выбрасывает все assert-строки из байт-кода, будто их не писали. Внутри программы за это отвечает имя __debug__: в обычном режиме оно True, под -O — False:

print('__debug__:', __debug__)

try:
    assert False, 'эта проверка всегда проваливается'
except AssertionError as e:
    print('поймали:', e)

__debug__: True
поймали: эта проверка всегда проваливается

python -O script.py

Ловушка: assert с кортежем

Классический нож в спину: скобки вокруг проверки. Кажется, что (2 + 2 == 5, 'сообщение') — это условие с текстом. На деле скобки создали кортеж из двух элементов, а непустой кортеж истинен всегда — как любое непустое значение Python. Проверка не сработает никогда, даже когда условие ложно:

try:
    assert (2 + 2 == 5, 'дважды два не пять')
    print('assert промолчал: скобки сделали кортеж, а он всегда истинен')
except AssertionError:
    print('сюда не попадём')

assert промолчал: скобки сделали кортеж, а он всегда истинен

Python даже подсказывает в предупреждении SyntaxWarning: assertion is always true, perhaps remove parentheses — но предупреждение не ошибка, и код выполняется. Правильная форма — без скобок: assert условие, 'сообщение'. Запятая здесь разделяет два аргумента, скобки не нужны.

assert или raise

Оба инструмента поднимают исключение с сообщением — разница в договоре. assert кричит «сломался мой код», ValueError — «сломались данные». Проверим оба на одном отрицательном возрасте:

def set_age_assert(age):
    assert age >= 0, 'возраст не может быть отрицательным'

def set_age_raise(age):
    if age < 0:
        raise ValueError('возраст не может быть отрицательным')

for func in (set_age_assert, set_age_raise):
    try:
        func(-5)
    except Exception as e:
        print(type(e).__name__, '-', e)

AssertionError - возраст не может быть отрицательным
ValueError - возраст не может быть отрицательным

Где assert уместен

• пред-условия функции: assert items, 'список не должен быть пустым' — договор о том, что функция принимает;
• пост-условия: assert result <= total, 'доля не может быть больше целого' — договор о том, что функция возвращает;
• невозможные ветки: в else варианта, которого не бывает, — assert False, f'неожиданное значение: {n}';
• тесты: фреймворк pytest строит все проверки на assert — об этом отдельный курс.

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

def classify(n):
    if n > 0:
        return 'положительное'
    elif n < 0:
        return 'отрицательное'
    else:
        assert False, f'неожиданное значение: {n}'

print(classify(5))
try:
    classify(0)
except AssertionError as e:
    print('попали в невозможную ветку:', e)

положительное
попали в невозможную ветку: неожиданное значение: 0

Ноль занял ветку, которую считали невозможной, — и assert сразу назвал значение. Это типичная работа инварианта: не обрабатывать случай, а громко заявить, что представление о коде разошлось с реальностью. Для данных пользователя по-прежнему if и raise, а граница между этими решениями — тема следующего урока.