Python: задачки и вопросы

Развёрнутое пояснение: 1. make_handlers создаёт пустой список handlers. 2. Цикл дважды присваивает переменной status значения 'new' и 'done'. 3. На каждой итерации создаётся lambda, но текущее значение status внутрь неё не копируется. 4. После цикла обе функции обращаются к одной переменной status, сохранившей последнее значение 'done'. 5. Последовательный вызов обработчиков поэтому возвращает список ['done', 'done']. Почему это важно Задача относится к позднему связыванию имён в замыканиях. Такая ситуация встречается при создании обработчиков событий и отложенных задач в цикле: без отдельной фиксации значения все обработчики могут работать с последним элементом.

Развёрнутое пояснение: 1. Вызов build_batch создаёт генератор, но его тело пока не исполняется. 2. list начинает потреблять этот генератор, и build_batch передаёт управление load_orders через yield from. 3. load_orders выдаёт строку order-1, поэтому она попадает в список, собираемый функцией list. 4. Затем load_orders выполняет return 1: для генератора это завершение со значением 1, а не выдача ещё одного элемента. 5. yield from извлекает это значение завершения и присваивает его переменной loaded. 6. Внутренний print выводит loaded 1, после чего build_batch завершается. 7. list возвращает список из единственного выданного элемента, и внешний print выводит ['order-1'] второй строкой. Почему это важно Задача относится к делегированию генераторов. Значение return вложенного генератора можно использовать как итог обработки, например как число загруженных записей, но оно не становится элементом ленивого потока.

Развёрнутое пояснение: 1. При входе в блок with вызывается метод __enter__, который печатает begin. 2. Тело блока печатает write, после чего возбуждает исключение ValueError. 3. Перед выходом из блока Python вызывает __exit__ и передаёт ему тип, значение и трассировку исключения. 4. __exit__ печатает имя типа исключения — ValueError — и возвращает True. 5. Истинное возвращаемое значение сообщает Python, что исключение обработано, поэтому строка после блока выполняется и печатает continued. Итоговый вывод: begin, write, ValueError и continued на отдельных строках. Почему это важно Задача проверяет протокол менеджеров контекста. На практике __exit__ часто освобождает соединения, завершает транзакции и управляет распространением ошибок; случайное возвращение истинного значения может скрыть сбой и позволить программе продолжить работу с некорректным состоянием.

Развёрнутое пояснение: 1. Для класса Client строится порядок разрешения методов: Client, Audit, Retry, Base, object. 2. Вызов send сначала находит реализацию в Audit, которая создаёт список с элементом audit. 3. super() внутри Audit продолжает поиск после Audit, поэтому вызывает Retry.send, а не Base.send напрямую. 4. Retry добавляет retry и через свой super() передаёт управление методу Base.send. 5. Base.send возвращает список с base; результаты последовательно объединяются, поэтому вывод равен ['audit', 'retry', 'base']. Почему это важно: задача проверяет кооперативное наследование и порядок разрешения методов. Такой подход применяется в примесях для журналирования, повторных попыток и проверки доступа; каждый класс должен передавать управление через super(), чтобы вся цепочка выполнилась.

Развёрнутое пояснение: 1. defaultdict(int) создаёт словарь, в котором фабрика int возвращает 0 для отсутствующего ключа. 2. Выражение errors['api'] += 1 сначала получает значение 0, увеличивает его и сохраняет 1 для ключа 'api'. 3. Обращение errors['db'] не вызывает KeyError: defaultdict вызывает int без аргументов, получает 0 и добавляет пару 'db': 0. 4. Первый print выводит 0, а второй — обычное представление словаря с ключами в порядке их добавления: {'api': 1, 'db': 0}. Почему это важно Задача относится к поведению defaultdict при чтении отсутствующих ключей. В счётчиках метрик простая проверка значения может незаметно изменить словарь, создать лишние записи и повлиять на последующую сериализацию или обход данных.

Развёрнутое пояснение: 1. При создании класса __slots__ разрешает экземплярам хранить атрибут lines, но не создаёт для них словарь __dict__. 2. Декоратор cached_property заменяет метод total дескриптором, который должен один раз вычислить результат и записать его в __dict__ экземпляра. 3. Конструктор успешно сохраняет переданный список в предусмотренный слот lines. 4. При чтении total дескриптор сначала пытается получить __dict__ объекта для будущей записи кэшированного значения. До вызова функции с sum дело не доходит. 5. Поскольку у экземпляра нет __dict__, cached_property возбуждает TypeError. Аргумент print не вычислен, поэтому в стандартный вывод ничего не попадает. Почему это важно Задача относится к взаимодействию дескрипторов и модели хранения атрибутов. В проектах __slots__ применяют для сокращения памяти, а cached_property — для ленивых вычислений. Их прямое сочетание требует добавить __dict__ в __slots__ либо выбрать другой способ хранения кэша.

Развёрнутое пояснение: 1. Создаётся функция load_rate, которая при вызове печатает строку «резерв» и возвращает 99. 2. В словарь rates записывается существующий тариф standard со значением 10. 3. Перед вызовом rates.get Python вычисляет все переданные аргументы, включая выражение load_rate(). 4. load_rate печатает «резерв» и возвращает 99, которое становится запасным значением для get. 5. Метод get находит ключ standard, поэтому возвращает 10, а уже вычисленное запасное значение 99 не использует. 6. Последний print выводит 10, поэтому итоговый вывод состоит из строк «резерв» и «10». Почему это важно Задача проверяет порядок вычисления аргументов функции. В реальном проекте передача затратной загрузки или запроса к резервному сервису прямо в dict.get может выполнять лишнюю работу даже при наличии ключа. Для ленивого получения запасного значения сначала проверяют наличие ключа или используют другую явную ветвь выполнения.