3. ChainMap(user, defaults) формирует цепочку поиска: сначала user, затем defaults.
4. Чтение config['theme'] не находит ключ в user и возвращает 'light' из defaults.
5. Запись config['theme'] = 'dark' всегда изменяет первый словарь цепочки, то есть user.
6. В user появляется {'theme': 'dark'}, а defaults остаётся {'theme': 'light'}.
7. print(defaults['theme']) выводит 'light'.
Почему это важно: ChainMap удобен для многоуровневых настроек — базовые значения, пользовательские, аргументы командной строки. Важно помнить, что присваивание пишет только в первый словарь, иначе можно случайно изменить общие дефолты или, наоборот, удивиться, почему изменение не дошло до последующих читателей конфига.
2. Запускается цикл for key in d. Python создаёт итератор словаря, который фиксирует его текущий размер.
3. На первой итерации key равно 'a'. Выполняется d['a_copy'] = 1, и размер словаря увеличивается.
4. Когда цикл пытается перейти к следующей итерации, итератор обнаруживает изменение размера и выбрасывает RuntimeError: dictionary changed size during iteration.
5. Программа завершается с этой ошибкой, print(d) не выполняется.
Почему это важно: при обработке конфигов, метрик или логов часто хочется на ходу добавлять производные ключи в тот же словарь, но это приводит к падению. Правильный путь — собирать изменения в отдельную структуру, а затем обновлять оригинал.
1. Определяется класс Key с методом __eq__, который сравнивает атрибут val.
2. В Python класс, определяющий __eq__, но не определяющий __hash__, автоматически получает __hash__ = None.
3. При выполнении строки cache = {Key(1): 'hit'} Python пытается вычислить хеш ключа, чтобы разместить его в словаре.
4. Поскольку Key.__hash__ равен None, объект считается нехешируемым, и создание словаря падает с TypeError: unhashable type: 'Key'.
5. Вызов cache.get(Key(1)) не выполняется, потому что программа прерывается раньше.
Почему это важно: кастомные ключи для кэшей, конфигураций или агрегаций часто требуют своего сравнения. Если забыть реализовать __hash__, весь механизм ломается ещё на этапе создания dict или set. В dataclasses это решается через frozen=True для автоматического __hash__, а в собственных классах — явным определением __hash__.
1. Первый вызов `load_users('a')` не находит ключ в кэше, выполняет `return []`, сохраняет созданный список в кэше и сразу добавляет в него `'u1'` через `.append`. Теперь в кэше лежит список `['u1']`.
2. Второй вызов `load_users('a')` попадает в кэш и возвращает тот же самый объект-список, а не новый. `.append('u2')` изменяет этот же объект, и он становится `['u1', 'u2']`.
3. Вызов `print(load_users('a'))` снова получает тот же объект из кэша и печатает `['u1', 'u2']`.
Почему это важно: кэширование изменяемых объектов — распространённая ловушка при оптимизации репозиториев, загрузчиков конфигурации и API-клиентов. Если возвращаемый объект мутируется, кэш превращается в разделяемое изменяемое состояние, и разные вызовы начинают влиять друг на друга, что приводит к трудноуловимым багам в продакшене.
В сигнатуре функции f параметры a и b стоят до /, поэтому их можно передать только позиционно. Параметр d стоит после *, поэтому его можно передать только по имени. Параметр c находится между / и *, поэтому допускает оба варианта. Корректен вызов с позиционными a, b и именованными c, d.
Привет! Весь июль мы будем вести этот канал в партнёрстве с Яндекс Практикумом PRO.
Драматически ничего не меняется: мы продолжим выкладывать задачки и решения — даже более системно и регулярно, чем последние пару месяцев. А ещё расскажем про большой мидловый курс по Python.
Для нас это новый формат соседства двух брендов — надеемся, будет полезно. А пока, всем отличных выходных 🌴
Код удаляет ключ 'a', после чего порядок становится ['b']. Затем 'a' вставляется заново, а не восстанавливается на старом месте, поэтому итоговый порядок — ['b', 'a']. Это поведение гарантировано с Python 3.7.
PY