Краткий ответ

Замыкание обычно нельзя сериализовать стандартным модулем pickle, потому что оно представляет локальную функцию вместе с захваченным состоянием. Экземпляр вызываемого класса часто сериализуется, если его класс доступен на уровне модуля, а все поля экземпляра поддерживают pickle.

Это важно при передаче задач рабочим процессам: объект должен быть преобразован в поток байтов и восстановлен в другом процессе. Однако это не абсолютное правило: конкретный результат зависит от способа запуска процессов, используемого механизма передачи и содержимого состояния.

Исторический контекст

Процессы имеют раздельные адресные пространства, поэтому функция и данные из одного процесса не могут напрямую использоваться другим процессом. Для передачи задания Python применяет сериализацию, а стандартным механизмом для многих сценариев multiprocessing служит pickle.

Замыкания удобны для инкапсуляции небольшого состояния без создания отдельного класса. Но стандартная сериализация Python исторически ориентирована прежде всего на восстановление объектов по имени модуля и имени класса или функции, а не на перенос произвольного локального окружения функции.

Постановка проблемы

Локальная функция, возвращённая из другой функции, обычно не имеет доступного для pickle глобального имени. Поэтому попытка отправить такое замыкание в пул процессов может завершиться ошибкой сериализации ещё до выполнения обработчика.

Неверное решение проявляется не всегда сразу: при некоторых сценариях с fork уже созданный процесс может унаследовать память родителя, но задания, передаваемые через очереди или пул, всё равно обычно сериализуются. Кроме того, spawn, используемый, в частности, на Windows, требует особенно явной сериализуемости объектов.

Подробное решение

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

Вызываемый экземпляр обычно сериализуется как экземпляр класса: pickle сохраняет ссылку на класс и состояние объекта. После восстановления метод __call__ снова определяет поведение объекта. Это работает, если класс импортируем из модуля верхнего уровня, а его атрибуты сериализуемы.

import pickle

def make_handler(prefix):
    def handler(value):
        return prefix + value
    return handler

class Handler:
    def __init__(self, prefix):
        self.prefix = prefix

    def __call__(self, value):
        return self.prefix + value

for item in (make_handler("A"), Handler("A")):
    try:
        pickle.dumps(item)
        print("сериализуем")
    except Exception as error:
        print(type(error).__name__)

В типичной реализации замыкание вызовет ошибку, а экземпляр Handler будет сериализован. Точный тип и текст исключения не следует считать частью контракта: важен сам факт, что стандартный pickle не обязан поддерживать локальное замыкание.

У callable-объекта есть и ограничения. Если его состояние содержит открытый файл, сетевое соединение, блокировку, генератор или другой несериализуемый объект, обычный pickle также не сработает. Иногда состояние можно преобразовать через __getstate__ и __setstate__, но ресурс обычно нужно открывать заново уже в рабочем процессе, а не пытаться передать сам дескриптор.

Альтернативой могут быть библиотеки вроде cloudpickle, способные сериализовать больше разновидностей функций и замыканий. Это повышает гибкость, но добавляет зависимость, может усложнить совместимость и не отменяет требований к сериализуемости захваченных объектов. Для долгоживущих систем часто предпочтительнее передавать имя операции и простые данные, а не сериализовать произвольный исполняемый код.

Ситуация из практики

Сервис формирует задания для пула процессов и хочет настроить обработчик префиксом. Первый вариант — фабрика, возвращающая замыкание. В однопоточном коде он прост и хорошо скрывает состояние, но при отправке задания в пул стандартная сериализация может завершиться ошибкой.

Второй вариант — callable-класс. Он требует нескольких строк шаблонного кода, зато состояние явно представлено полями, а объект обычно совместим с pickle. Недостаток остаётся прежним: каждое поле должно быть сериализуемым, а внешние ресурсы нельзя бездумно хранить в экземпляре.

Третий вариант — применить cloudpickle. Он удобен, если действительно нужно передавать динамически созданные функции, но увеличивает инфраструктурную связанность и не решает проблему несериализуемых ресурсов.

Практический выбор — callable-класс с простыми данными конфигурации, например строками и числами. В рабочем процессе обработчик создаёт соединения и другие ресурсы локально, поэтому передача задания становится предсказуемой и не зависит от случайного поведения конкретного способа запуска процессов.

Что кандидаты часто упускают

1. Почему функция верхнего уровня обычно сериализуется, а вложенная функция — нет?

pickle обычно сохраняет функцию верхнего уровня через её модуль и имя, а при восстановлении импортирует объект по этому пути. Вложенная функция имеет локальную область определения и не может быть надёжно найдена по глобальному имени. Даже если она не захватывает переменные, факт вложенности уже может сделать её несовместимой со стандартным pickle.

2. Достаточно ли сделать класс вызываемым, чтобы гарантировать сериализацию его экземпляра?

Нет. Наличие __call__ отвечает только за возможность вызова объекта и не определяет правила сериализации. Класс должен быть доступен при импорте в рабочем процессе, а состояние экземпляра — поддерживать используемый протокол pickle; иначе потребуется изменить состояние или явно реализовать его восстановление.

3. Почему замена замыкания на callable-класс не гарантирует одинаковое поведение?

Замыкание захватывает ссылки на внешние переменные, а callable-класс обычно сохраняет значения в атрибутах. Если внешнее состояние изменяется после создания замыкания, либо содержит общий изменяемый объект, семантика может отличаться. При передаче в другой процесс также исчезает совместное владение памятью: сериализуется снимок состояния, а не живая общая ссылка.