Коллекции

Выбор коллекции под задачу

Содержание курса

Типичные ошибки при выборе коллекции

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

Ошибка 1: список вместо множества — дубли накапливаются незаметно

Представь, что интернет-магазин собирает теги товаров из разных источников. Один и тот же тег может прийти несколько раз, но в итоговом наборе каждый тег должен быть ровно один раз.

tags = []

tags.append("электроника")
tags.append("смартфоны")
tags.append("электроника")  # пришёл повторно из другого источника
tags.append("смартфоны")   # и этот тоже
tags.append("гаджеты")

print(len(tags))   # 5 — но уникальных тегов только 3
print(tags)        # ['электроника', 'смартфоны', 'электроника', 'смартфоны', 'гаджеты']

Программа не сломается, но данные окажутся неверными: при подсчёте «сколько уникальных тегов у товара» получим завышенное число. Чтобы исправить это постфактум, придётся писать list(set(tags)) или проверять if tag not in tags перед каждым добавлением. Множество решает задачу на уровне структуры:

tags = set()
tags.add("электроника")
tags.add("смартфоны")
tags.add("электроника")  # дубль — просто игнорируется
tags.add("смартфоны")
tags.add("гаджеты")

print(len(tags))  # 3 — сразу верно

Никаких дополнительных проверок не нужно: дубль не попадёт в структуру по определению.

Ошибка 2: попытка изменить кортеж — TypeError в рантайме

Кортеж выглядит как список, но изменить его нельзя. Если выбрать кортеж для данных, которые должны меняться, программа упадёт:

point = (53.9, 27.5)
point[0] = 55.0  # хотим обновить широту
TypeError: 'tuple' object does not support item assignment

Эта ошибка неприятна тем, что часто обнаруживается не сразу: кортеж создаётся в одном месте программы, а попытка изменить его — в другом, уже во время работы. Если данные должны обновляться — это список. Кортеж выбирают именно тогда, когда неизменность нужна как гарантия, а не случайно.

Ошибка 3: список вместо словаря — поиск по индексу вместо поиска по смыслу

Допустим, нужно хранить характеристики пользователя: имя, возраст, email. Если сложить всё в список:

user = ["Алиса", 29, "alice@example.com"]
print(user[2])  # email — надо помнить, что он третий

Пока элементов три, это ещё терпимо. Но если список пополнится — скажем, между именем и возрастом появится телефон — индексы сдвинутся, и user[2] уже будет не email, а возраст. Ошибка тихая: Python не предупредит, вернёт просто не то значение.

Словарь фиксирует смысл прямо в коде:

user = {
    "name": "Алиса",
    "age": 29,
    "email": "alice@example.com"
}
print(user["email"])  # всегда email, независимо от порядка

Добавить новое поле можно в любое место — доступ по ключу не сломается. Список для именованных данных требует держать в голове позицию каждого элемента; словарь убирает эту зависимость полностью.

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

Начать заново?

Помощник начнёт новый диалог по этой задаче. Текущая переписка останется в истории до конца срока хранения.

О переписке

Можно приложить до трёх фото PNG, JPEG или WebP по 5 МБ.

Переписка и фото хранятся 90 дней после последнего принятого сообщения. Преподаватель получит доступ к диалогу, когда вы попросите его помочь.

Проверка решения остаётся отдельным действием.