Das Protokoll des pickle-Moduls hat sich weiterentwickelt, um Objekte zu handhaben, bei denen __init__ Nebenwirkungen oder teure Berechnungen hat. Frühere Protokolle erforderten, dass __init__ während des Unpickelns aufgerufen wird, was Probleme mit Ressourcen wie Datei-Handles oder Datenbankverbindungen verursachte. Protokoll 2 führte __getnewargs__ ein, und Protokoll 4 erweiterte dies mit __getnewargs_ex__, um Schlüsselwortargumente zu unterstützen und eine feiner abgestimmte Kontrolle über die Objektrekonstruktion zu ermöglichen.
Beim Unpickeln von Objekten muss Python typischerweise den Objektzustand wiederherstellen. Wenn __init__ Validierungen durchführt, Netzwerksockets öffnet oder den globalen Zustand ändert, kann das erneute Ausführen während des Unpickelns falsch oder ineffizient sein. Die Herausforderung besteht darin, den Objektzustand wiederherzustellen, ohne diese Initialisierungsnebenwirkungen auszulösen, indem nur die gespeicherten Daten verwendet werden, um die Instanz über den niedrigeren Konstruktor __new__ zu rekonstruieren.
Die dunder-Methode __getnewargs_ex__ (oder __getnewargs__ für ältere Protokolle) erlaubt es einer Klasse, ein Tuple von (args, kwargs) zurückzugeben, das pickle direkt an __new__ übergibt und __init__ vollständig überspringt. Diese Methode wird während der Rekonstruktionsphase aufgerufen, und ihr Rückgabewert bestimmt, wie die Instanz aus den serialisierten Bytes erstellt wird. Dieser Ansatz stellt sicher, dass das Objekt mit dem korrekten Anfangszustand instanziiert wird, ohne irgendwelche Initialisierungslogik aufzurufen, die für ein wiederhergestelltes Objekt unangemessen sein könnte.
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): # Teure Operation, die wir während des Unpickelns überspringen möchten self.socket = create_socket(dsn, timeout) def __getnewargs_ex__(self): # Rückgabe von args und kwargs für __new__ return ((self.dsn,), {'timeout': self.timeout}) def __getstate__(self): # Socket nicht picklen return {'dsn': self.dsn, 'timeout': self.timeout} def __setstate__(self, state): self.dsn = state['dsn'] self.timeout = state['timeout'] # Socket falls nötig wiederherstellen oder für späte Initialisierung beiseite lassen # Nutzung conn = DatabaseConnection('postgresql://localhost', timeout=60) serialized = pickle.dumps(conn, protocol=4) restored = pickle.loads(serialized) # __init__ wird nicht aufgerufen
Ein Datenverarbeitungspipeline speichert Redis-Verbindungsobjekte zwischen, die offene TCP-Sockets und Authentifizierungstoken halten. Beim Serialisieren dieser Cache-Elemente auf die Festplatte, um die Persistenz zwischen den Neustarts der Anwendung sicherzustellen, versucht das Aufrufen von __init__ während des Unpickelns sofort, neue Socketverbindungen herzustellen, was in Offline-Umgebungen fehlschlägt oder Ressourcenlecks verursacht. Dieses Szenario erfordert eine Serialisierungsstrategie, die Verbindungsparameter beibehält, während die tatsächliche Netzwerkinitialisierung bis zur ausdrücklichen Anforderung der Anwendung hinausgeschoben wird.
Implementieren Sie __getstate__, um nur die Verbindungsparameter (Host, Port, Auth) zurückzugeben, und __setstate__, um Attribute manuell festzulegen und optional die Verbindung wiederherzustellen. Dieser Ansatz ist mit älteren pickle-Protokollen kompatibel und explizit. Dennoch ruft er während des standardmäßig unpickelnden Prozesses immer noch __init__ auf, es sei denn, dies wird sorgfältig mit __reduce__ vermieden, was potenziell Nebenwirkungen auslösen kann, bevor __setstate__ bereinigen kann.
Implementieren Sie __reduce__, um ein Tuple von (callable, args, state) zurückzugeben, wobei das Callable eine Klassenmethode oder __new__ selbst ist. Dies bietet vollständige Kontrolle über die Rekonstruktion, ist jedoch ausführlich und erfordert eine manuelle Verwaltung des Zustandswörterbuchs. Dies erhöht die Komplexität des Codes und das Risiko von Versionsinkonsistenzen zwischen der Klassenstruktur und den pickled Daten.
Implementieren Sie __getnewargs_ex__, um ((host, port), {'auth': token}) zurückzugeben, sodass pickle __new__(host, port, auth=token) direkt aufruft und __init__ umgeht. Diese Lösung wurde gewählt, weil sie die modernen Protokoll 4-Funktionen nutzt, die Phase 'leere Instanz erstellen' klar von der Phase 'Ressourcen initialisieren' trennt und die Boilerplate von __reduce__ vermeidet. Das Ergebnis ist ein robustes Caching-System, bei dem Verbindungsobjekte mit ihrer Konfiguration intakt wiederhergestellt werden, die Sockets jedoch geschlossen bleiben, bis sie ausdrücklich benötigt werden, wodurch die Erschöpfung von Ressourcen während batch-Wiederherstellungsoperationen verhindert wird.
Warum verhindert __getnewargs_ex__, dass __init__ aufgerufen wird, während __setstate__ allein dies nicht tut?
Wenn pickle ein Objekt rekonstruiert, prüft es auf __getnewargs_ex__ (oder __getnewargs__). Ist dies vorhanden, ruft der Unpickler __new__(*args, **kwargs) mit den zurückgegebenen Werten auf und wendet sofort den Zustand über __setstate__ an, falls verfügbar, und überspringt damit __init__ vollständig. Im Gegensatz dazu verwendet pickle ohne diese Methoden den standardmäßigen Konstruktionspfad, der immer __init__ nach __new__ aufruft. Kandidaten nehmen oft an, dass __setstate__ die Initialisierung überschreibt, aber __setstate__ patcht lediglich die Instanz, nachdem __init__ bereits ausgeführt wurde, was zu spät ist, um Nebenwirkungen zu verhindern.
Was passiert, wenn __getnewargs_ex__ einen Wert zurückgibt, der kein Tuple aus zwei Elementen ist?
Das pickle-Protokoll erfordert streng, dass __getnewargs_ex__ ein Tuple der Länge 2 zurückgibt: (args_tuple, kwargs_dict). Wenn es ein einzelnes Tuple von Argumenten (wie __getnewargs__) zurückgibt, wird Python während des Unpickelns einen TypeError auslösen, da es versucht, das Ergebnis in __new__(*args, **kwargs) zu entpacken. Wenn es None oder andere Typen zurückgibt, kann der Unpickler abstürzen oder unvorhersehbar reagieren, was sich von __getnewargs__ unterscheidet, das nur ein Tuple von Argumenten erwartet.
Wie interagieren __getnewargs_ex__ und __reduce_ex__, wenn beide definiert sind?
__reduce_ex__ ist die höherstufige Protokollmethode, die die Serialisierung orchestriert. Wenn eine Klasse __getnewargs_ex__ definiert, integriert __reduce_ex__ (insbesondere bei Protokoll 4+) automatisch deren Rückgabewert in das Reduktions-Tuple unter Verwendung des NEWOBJ_EX-Opcodes. Wenn beide vorhanden sind, aber __reduce_ex__ ein benutzerdefiniertes Callable zurückgibt, das nicht den standardmäßigen Rekonstruktionspfad verwendet, hat es Vorrang und ignoriert möglicherweise __getnewargs_ex__ vollständig.