Краткий ответ

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

Исторический контекст

Протокол итераторов Python использует StopIteration для служебной сигнализации: очередного элемента больше нет. Такой механизм позволяет циклу for автоматически отличать обычное значение от конца обхода.

Форма next с запасным значением решает практическую задачу ручного получения одного элемента без обязательного try/except. Она особенно полезна для необязательного чтения данных, когда отсутствие элемента не является ошибкой.

Постановка проблемы

Если вызвать next без запасного значения после исчерпания итератора, возникнет StopIteration. При передаче запасного значения исключение наружу не выйдет, поэтому вызывающий код может продолжить работу как с обычным результатом.

Главный риск — потерять различие между реальным элементом и запасным значением. Например, если запасным объектом выбран None, невозможно по одному результату понять, был ли None получен из итератора или возвращён из-за его завершения.

Подробное решение

Вызов next(итератор, запасное_значение) пытается получить следующий элемент через протокол итератора. Если элемент найден, возвращается именно он, включая None, 0 или False; запасное значение в этом случае игнорируется.

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

iterator = iter([10])

print(next(iterator, "конец"))
print(next(iterator, "конец"))
print(next(iterator, "конец"))

В первом вызове будет получено 10, а во втором и третьем — строка "конец". Для обработки результата без неоднозначности используют уникальный объект-сентинел, который не может быть обычным элементом потока.

Форма с запасным значением отличается от подавления любых исключений: она предназначена именно для штатного завершения итератора. Ошибки вроде ValueError или TypeError не превращаются в запасное значение и должны обрабатываться отдельно.

Ситуация из практики

Сервис читает необязательный первый элемент из итератора записей. Вариант с try/except StopIteration явно разделяет найденную запись и отсутствие данных, но занимает больше кода. Вариант с next(iterator, None) короче, однако небезопасен, если None допустим среди реальных записей.

Можно выбрать специальную строку вроде "нет данных", но она тоже теоретически может встретиться в потоке и создать коллизию. Надёжное решение — использовать уникальный объект-сентинел, сравнивать результат с ним по идентичности и отдельно обрабатывать найденное значение.

Такой подход сохраняет компактность next с запасным значением и одновременно не смешивает отсутствие элемента с любым допустимым содержимым данных. Для публичного API вместо внутреннего сентинела обычно возвращают более явно описанный результат, например пару из признака наличия и значения.

Что кандидаты часто упускают

Что произойдёт, если сам итератор возвращает значение, равное запасному объекту?

next не различает такие случаи по равенству значений. Если итератор действительно вернул объект, совпадающий с запасным, наружу будет возвращён этот реальный объект, но вызывающий код не сможет отличить его от результата при завершении. Поэтому для проверки используют уникальный объект и сравнение через is, а не ==.
Меняет ли запасное значение состояние итератора после его исчерпания?

Нет. Итератор остаётся исчерпанным, а запасное значение лишь возвращается вызывающему коду. Повторный вызов не возобновит обход и снова вернёт запасное значение, если итератор не имеет нестандартной реализации протокола.
Какие исключения подавляет форма next с двумя аргументами?

Она заменяет только нормальный сигнал завершения итератора — StopIteration. Исключения, указывающие на ошибку вычисления или нарушение контракта объекта, например ValueError, TypeError или исключение из пользовательского __next__, не должны маскироваться запасным значением и передаются вызывающему коду.