Диагностика ошибки с достаточными данными

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

Случай связан с вызовом featured_pages(rows, True). Контракт требует целое число от одного до пяти и отдельно исключает логический тип. Возможный кандидат использует isinstance, а окончательный код — точную проверку type(limit) is int. После урока вы сможете сформулировать минимальные данные для исправления подобной ошибки и объяснить, почему изменять отбор страниц при этом не требуется.

Вход важнее впечатления

Фраза «функция выдаёт неправильный результат» не сообщает, какой путь привёл к проблеме. Нужно назвать версию исходников, функцию, аргумент и используемые записи. Для нашего случая достаточно текущего корпуса и логического лимита. Текст Markdown не влияет на проверку типа, поэтому прикладывать все статьи в диагностическое сообщение незачем. Чем точнее выделены существенные входы, тем проще рассуждать о причине и меньше риск случайной передачи лишних данных.

Запишем ожидаемое поведение отдельно: отказ из-за недопустимого типа до формирования рекомендуемой подборки. Если самостоятельный запуск позже покажет выдачу одной карточки, это будет наблюдаемое нарушение. Пока мы объясняем возможный результат по устройству Python. Нельзя записать выдуманный traceback и представить его как полученный. Можно привести форму ожидаемого сообщения и указать, что она относится к предложенному учебному варианту, который читатель может исследовать сам.

Разница между True и 1 не косметическая. Оба значения могут участвовать в похожих числовых выражениях, но в нашей границе имеют разный смысл. 1 означает запрос одной записи, True — логический признак, случайно переданный в числовой параметр. Если интерфейс смешал их, молчаливое принятие скрывает ошибку вызывающего кода. Поэтому задача состоит в восстановлении договорённости о типе, а не в поиске способа получить подходящее количество карточек.

Проверка типа и причины

isinstance учитывает отношение наследования. Это полезно, когда функция должна принимать разные реализации общего интерфейса, но не подходит для каждого предметного ограничения. В рассматриваемом Python-профиле bool связан с int, поэтому проверка принадлежности к целому допускает логическое значение. Точное сравнение type исключает подклассы. Такое решение сознательно узкое: мы не принимаем пользовательские числовые классы, поскольку контракт требует обычное целое число Python.

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

Не стоит решать проблему преобразованием int(limit). Тогда True станет единицей, строка с цифрой также превратится в число, а часть дробных значений может потерять смысл. Преобразование является отдельной политикой ввода. Она может быть полезна на уровне формы, но должна иметь свои правила: допустимы ли пробелы, знак, дробь и пустое поле. Внутренняя функция отбора получает уже разобранное значение и не угадывает намерение вызывающего кода.

Узкое исправление

Диагностическая карточка указывает область правки: условие limit, без изменения public_pages, featured и URL. Это помогает исполнителю не реагировать на слово «ошибка» большим рефакторингом. Иногда дефект действительно требует архитектурного изменения, но оно должно следовать из анализа причины. Здесь проблема локализована в одном условии. Смена хранилища, добавление библиотеки схем или переписывание всего каталога не нужны для восстановления данного договора.

Кроме ошибочного входа полезно назвать соседние допустимые случаи. Для limit=1 ожидается первая рекомендация в устойчивом порядке; для значения по умолчанию — две. Это не означает, что мы запускаем проверки в подготовке. Соседние ожидания объясняют, какое поведение правка должна сохранить. Без них исполнитель может «исправить» ошибку отказом при любом переданном аргументе и формально исключить bool, потеряв полезный параметр функции.

Если вы позже получите фактический сбой, сохраняйте его рядом с исходным состоянием: название команды, версия Python, аргументы и сообщение. Отделяйте вывод программы от собственного объяснения. Вывод отвечает на вопрос «что наблюдалось», объяснение — «какая причина предполагается». При повторном исследовании причина может уточниться, но исходные данные останутся полезны. Такой формат поддерживает спокойный разговор с агентом без повторения всей истории работы.

Ожидаемый результат чтения окончательного кода — отказ для True, нуля, строки и значений выше пяти при сохранении обычных лимитов. Это статическое основание, а не отчёт о выполнении. В архивной карточке явно указано происхождение учебного случая. Если программа запускается в другой версии или модифицированном состоянии, выводы нужно привязать к этой среде отдельно; название курса не гарантирует тождественность любой локальной копии.

Две ошибки с похожим симптомом

При limit=0 программа должна отказать из-за диапазона. При limit=True — из-за типа. Оба входа могут внешне привести к неожиданному количеству карточек в плохом кандидате, но причины различны. Если сообщить только «получилось мало ссылок», исполнитель может изменить default limit или добавить запасной набор. Это не исправит договор параметра. Поэтому диагностическое сообщение называет конкретное значение и категорию нарушения.

Вход '2' даёт ещё один полезный вариант. Если он пришёл из формы, проблема может находиться на границе интерфейса, который передал строку внутрь функции. Наш отбор не должен молча преобразовывать её, поскольку такое поведение не задано. Исправление может быть нужно вызывающему коду, но в учебной библиотеке такого интерфейса нет. Не придумывайте отсутствующий компонент как установленную причину.

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

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

Полный файл DIAGNOSIS.md из состояния lesson-07. Полное самостоятельное состояние находится в архиве серии; фрагмент не заменяет остальные определения.

# Учебный случай, не журнал выполненного запуска

Вход: featured_pages(rows, True).
Ожидается: ValueError invalid limit. Возможный дефект: True проходит isinstance(x,int).
Причина: bool является подклассом int. Исправление: точная проверка type.
Не менять: правило отбора и порядок; дефект связан только с границей лимита.

Статус примера: not_run. При подготовке не выполнялись учебные программы, тесты, вызовы AI или деплой. Описанные эффекты ожидаемые.

Оглавление серии · Полные исходники

Первичные документы: Источник 1.