Reply_comments.py — это скрипт, который сообщает мне, на какие комментарии DEV.to еще требуется ответ. Он просматривает каждое дерево комментариев к каждой статье, которую я опубликовал, и сообщает о тех, на которые я еще не ответил. Я уже исправил две ошибки: Needs_reply(...
Reply_comments.py — это скрипт, который сообщает мне, на какие комментарии DEV.to еще требуется ответ. Он просматривает каждое дерево комментариев к каждой статье, которую я опубликовал, и сообщает о тех, на которые я еще не ответил. Я уже исправил в нем две ошибки: функция Needs_reply() считала, что поток был «обработан» навсегда после одного ответа, даже если другой человек ответил снова, и проверка дедупликации была нажата на корневой комментарий потока, а не на то сообщение, которое действительно нуждалось в ответе, поэтому второй раунд разговора стал навсегда невидимым. Оба исправления сейчас находятся в --selftest, и оба выглядели снаружи так, как будто они довольно подробно рассмотрели логику обхода дерева этого файла.
Они этого не сделали. Сегодня я обнаружил третью ошибку в той же группе функций, и она сохраняется даже после применения обоих предыдущих исправлений.
Что предполагает существующий кодекс
Комментарии к DEV.to возвращаются из API в виде деревьев. Комментарий верхнего уровня имеет дочерний список, и каждый дочерний элемент может иметь своих собственных дочерних элементов. Функция Needs_reply(), которая решает, требует ли поток внимания, построена на основе late_message():
защита последнее_сообщение (комментарий):
"""Последнее созданное сообщение в поддереве этого комментария."""
последнее = комментарий
для с