Смотрите внимательно как устроен ваш парсер. Вам уже намекнули в соседнем ответе.
Вы парсите статью так, будто бы её текст весь в одной строке (во второй по счету). А ссылки вы ищете в третьей строке, но из-за того, что статья многострочная там их нет.
Разбивайте задачу на маленькие подзадачи и делайте их отдельно, на каждом шагу убеждаясь, что всё как надо. Для этого можно делать отладочный выхлоп в промежуточных состояниях.
ВОт вы почему-то свято уверены, что lines[2][8:]
- это перечень ссылок через запятую. Может быть даже в одном из примеров в какой-то момент когда-то так оно и было, но с тех пор вы уже поменяли, скорее всего, код или входной формат, но не учли это.
Делайте больше отладочного вывода. Лучше не принтами, а с использованием модуля logging, тогда отладочный выхлоп можно включать и отключать при необходимости не трогая код.
Каждый раз, когда вы меняете код, не важно для исправления старых ошибок, или для добавления новой функциональности, вы неизбежно вносите новые ошибки.
Чтобы это контролировать пишут юнит-тесты. Но вам, похоже, еще рановато.
Ещё, особенно в небольших скриптах, полезно убеждаться, что всё идёт как надо в промежуточных этапах. Для этого в питоне есть ключевое слово assert.
Оно позволяет указать обязательное условие, которое должно соблюдаться в этом месте выполнения программы, и текст ошибки, с которой упадёт программа в этом месте, если условие не соблюдается.
Конкретно здесь, можно было бы убедиться с помощью assert, что в третьей строке вы отрезали 8 символов и эти символы соответствуют префиксу "Images: ".
Падение программы на этом месте даст вам понять, что вы где-то ошиблись и что-то пошло не так, как вы ожидали. Эти ассерты также помогут вам сразу обнаруживать изменение входного формата данных, за который, возможно, отвечает не ваш код.