Протокол модуля pickle развился, чтобы обрабатывать объекты, у которых __init__ имеет побочные эффекты или ресурсоемкие вычисления. Ранние протоколы требовали вызова __init__ при раскодировании, что вызывало проблемы с ресурсами, такими как файловые дескрипторы или соединения с базой данных. Протокол 2 представил __getnewargs__, а Протокол 4 расширил его с помощью __getnewargs_ex__, чтобы поддерживать именованные аргументы, предоставляя более тонкий контроль над восстановлением объекта.
При раскодировании объектов Python обычно необходимо восстановить состояние объекта. Если __init__ выполняет валидацию, открывает сетевые сокеты или изменяет глобальное состояние, повторное выполнение его во время раскодирования может быть некорректным или неэффективным. Задача состоит в том, чтобы восстановить состояние объекта, не активируя эти побочные эффекты инициализации, используя только сохраненные данные для реконструкции экземпляра через конструктор более низкого уровня __new__.
Метод __getnewargs_ex__ (или __getnewargs__ для более ранних протоколов) позволяет классу вернуть кортеж (args, kwargs), который pickle передает непосредственно в __new__, полностью пропуская __init__. Этот метод вызывается в ходе фазы реконструкции, и его возвращаемое значение определяет, как создается экземпляр из сериализованных байтов. Этот подход гарантирует, что объект создается с правильным начальным состоянием, не вызывая никакой логики инициализации, которая может быть неуместна для восстановленного объекта.
import pickle class DatabaseConnection: def __new__(cls, dsn, timeout=30): instance = super().__new__(cls) instance.dsn = dsn instance.timeout = timeout return instance def __init__(self, dsn, timeout=30): # Ресурсоемкая операция, которую мы хотим пропустить во время раскодирования self.socket = create_socket(dsn, timeout) def __getnewargs_ex__(self): # Вернуть args и kwargs для __new__ return ((self.dsn,), {'timeout': self.timeout}) def __getstate__(self): # Не сериализовать сокет return {'dsn': self.dsn, 'timeout': self.timeout} def __setstate__(self, state): self.dsn = state['dsn'] self.timeout = state['timeout'] # Восстановить сокет, если необходимо, или оставить для ленивой инициализации # Использование conn = DatabaseConnection('postgresql://localhost', timeout=60) serialized = pickle.dumps(conn, protocol=4) restored = pickle.loads(serialized) # __init__ не вызван
Конвейер обработки данных кэширует объекты соединения Redis, которые содержат открытые TCP сокеты и токены аутентификации. При сериализации этих кэшированных записей на диск для сохранения между перезапусками приложения вызов __init__ во время раскодирования пытается немедленно создать новые соединения сокетов, что завершится неудачей в оффлайн-режиме или создаст утечки ресурсов. Этот сценарий требует стратегии сериализации, которая сохраняет параметры соединения, откладывая фактическое создание сети до тех пор, пока приложение не запросит это явно.
Реализуйте __getstate__, чтобы вернуть только параметры соединения (хост, порт, аутентификация), и __setstate__, чтобы вручную установить атрибуты и при необходимости повторно открыть соединение. Этот подход совместим со старыми протоколами pickle и явен. Однако, он по-прежнему вызывает __init__ во время процесса по умолчанию раскодирования, если его аккуратно не избежать с помощью __reduce__, что потенциально приводит к побочным эффектам до того, как __setstate__ сможет очистить.
Реализуйте __reduce__, чтобы вернуть кортеж (callable, args, state), где вызываемый метод — это метод класса или сам __new__. Это обеспечивает полный контроль над реконструкцией, но является многословным и требует ручного управления словарем состояния. Это увеличивает сложность кода и риск несоответствий версий между структурой класса и сериализованными данными.
Реализуйте __getnewargs_ex__, чтобы вернуть ((host, port), {'auth': token}), позволяя pickle вызывать __new__(host, port, auth=token) напрямую, обходя __init__. Это решение было выбрано, поскольку использует современные функции протокола 4, четко разделяя этап 'создания пустого экземпляра' и 'инициализации ресурсов', и избегая лишнего кода __reduce__. В результате получается надежная система кэширования, где объекты соединения восстанавливаются с их конфигурацией, но сокеты остаются закрытыми до тех пор, пока не будут явно необходимы, что предотвращает истощение ресурсов во время пакетной операции раскодирования.
Почему __getnewargs_ex__ предотвращает вызов __init__, в то время как __setstate__ один лишь не делает этого?
Когда pickle восстанавливает объект, он проверяет наличие __getnewargs_ex__ (или __getnewargs__). Если он присутствует, распаковщик вызывает __new__(*args, **kwargs) с возвращаемыми значениями и немедленно применяет состояние через __setstate__, если оно доступно, полностью пропуская __init__. В отличие от этого, без этих методов pickle использует стандартный путь конструкции, который всегда вызывает __init__ после __new__. Кандидаты часто предполагают, что __setstate__ переопределяет инициализацию, но __setstate__ лишь устраняет проблемы экземпляра после того, как __init__ уже выполнен, что слишком поздно для предотвращения побочных эффектов.
Что происходит, если __getnewargs_ex__ возвращает значение, не являющееся кортежем из двух элементов?
Протокол pickle строго требует, чтобы __getnewargs_ex__ возвращал кортеж длиной 2: (args_tuple, kwargs_dict). Если он возвращает единый кортеж аргументов (как __getnewargs__), Python вызовет TypeError во время раскодирования, так как пытается распаковать результат в __new__(*args, **kwargs). Если он возвращает None или другие типы, распаковщик может аварийно завершить работу или вести себя непредсказуемо, что отличается от __getnewargs__, который ожидает только кортеж аргументов.
Как __getnewargs_ex__ взаимодействует с __reduce_ex__, когда оба определены?
__reduce_ex__ — это метод протокола более высокого уровня, который организует сериализацию. Если класс определяет __getnewargs_ex__, __reduce_ex__ (в частности, в протоколе 4+) автоматически включает его возвращаемое значение в кортеж уменьшения с использованием опкода NEWOBJ_EX. Если оба присутствуют, но __reduce_ex__ возвращает пользовательский вызываемый метод, не использующий стандартный путь реконструкции, он имеет приоритет, потенциально игнорируя __getnewargs_ex__ entirely.