# `pickle` --- Module de sérialisation d'objets Python

Code source : Lib/pickle.py

Le module `pickle` implémente des protocoles binaires de sérialisation et dé-sérialisation d'objets Python. Le pickling est le procédé par lequel une hiérarchie d'objets Python est convertie en flux d'octets. unpickling est l'opération inverse, par laquelle un flux d'octets (à partir d'un binary file ou bytes-like object) est converti en hiérarchie d'objets. Pickling (et unpickling) sont alternativement connus sous les termes de "sérialisation", de "marshalling" 1 ou encore de "flattening". Cependant pour éviter la confusion les termes utilisés ici sont pickling et unpickling.

Avertissement

Le module `pickle` n'est pas sécurisé. Ne désérialisez des objets qu'à partir de sources fiables.

Il est possible de produire des données binaires qui exécutent du code arbitraire lors de leur désérialisation. Ne désérialisez jamais des données provenant d'une source non fiable, ou qui pourraient avoir été modifiées.

Pensez au module `hmac` pour signer des données afin de s'assurer qu'elles n'ont pas été modifiées.

Des formats de sérialisation plus sûrs, comme `json`, peuvent se révéler plus adaptés si vous travaillez sur des données qui ne sont pas fiables. Voir Comparaison avec json.

## Relations aux autres modules python

### Comparaison avec `marshal`

Python possède un module de bas niveau en sérialisation appelé `marshal`, mais en général il est préférable d'utiliser `pickle` pour sérialiser des objets Python. `marshal` existe principalement pour gérer les fichiers Python en `.pyc`.

Le module `pickle` diffère du module `marshal` sur plusieurs aspects :

- Le module `pickle` garde la trace des objets qu'il a déjà sérialisés, pour faire en sorte que les prochaines références à cet objet ne soient pas sérialisées à nouveau. `marshal` ne le fait pas.

  Ça a des implications sur les objets partagés et les objets récursifs. Les objets récursifs sont des objets qui contiennent des références à eux-mêmes. Ceux-ci ne sont pas gérées par marshal : lui donner un objet récursif va le faire planter. Un objet est partagé lorsque que plusieurs références pointent dessus, depuis différents endroits dans la hiérarchie sérialisée. Le module `pickle` repère ces partages et ne stocke ces objets qu'une seule fois. Les objets partagés restent ainsi partagés, ce qui peut être très important pour les objets muables.

- `marshal` ne peut être utilisé pour la sérialisation et l'instanciation de classes définies par les utilisateurs. `pickle` peut sauvegarder et restaurer les instances de classes de manière transparente. Cependant la définition de classe doit être importable et lancée dans le même module et de la même manière que lors de son importation.

- Aucune garantie n'est offerte sur la portabilité du format `marshal` entre différentes versions de Python. Sa fonction première étant la gestion des fichiers `.pyc`, les développeurs se réservent le droit de changer le format de sérialisation de manière non-rétrocompatible si besoin était. Il est garanti que le format `pickle` restera compatible avec les versions futures de Python, pourvu que vous choisissiez un protocole de sérialisation adapté. De plus, il masque les différences entre les types Python 2 et Python 3, pour le cas où il s'agit de désérialiser en Python 3 des données sérialisées en Python 2.

### Comparaison avec `json`

There are fundamental differences between the pickle protocols and JSON (JavaScript Object Notation):

- pickle est un format binaire, tandis que JSON est un format textuel (constitué de caractères Unicode et généralement encodé en UTF-8) ;

- JSON peut être lu par une personne, contrairement à pickle ;

- JSON offre l'interopérabilité avec de nombreux outils en dehors de l'écosystème Python, alors que pickle est propre à Python ;

- Par défaut, JSON n'est capable de sérialiser qu'un nombre limité de types natifs Python, et ne prend pas en charge les classes définies par l'utilisateur. Le format pickle peut représenter une multitude de types d'objets, dont beaucoup automatiquement, grâce à une utilisation fine des possibilités d'introspection de Python ; on peut traiter les cas les plus complexes en implémentant des méthodes de sérialisation propres à une classe ;

- Contrairement à pickle, la désérialisation de données JSON n'ouvre pas en soi une vulnérabilité à l'exécution de code arbitraire.

Voir aussi

Le module `json` de la bibliothèque standard permet la sérialisation et désérialisation au format JSON.

## Format du flux de données

Le format de données employé par `pickle` est propre à Python, avec l'avantage qu'aucune restriction n'est imposée par des standards externes comme JSON ou XDR (qui ne peuvent pas représenter le partage de références). Cependant, cela signifie que des programmes écrits en d'autres langages que Python peuvent échouer à reconstituer les objets sérialisés.

Le format binaire `pickle` est, par défaut, une représentation assez compacte des objets. Il est possible de compresser efficacement les données sérialisées.

Le module `pickletools` contient des outils servant à analyser les flux de données générés par `pickle`. Le code source de `pickletools` contient des commentaires détaillés sur les opcodes employés par les protocoles pickle.

Il existe actuellement 6 protocoles différents pour la sérialisation. Les protocoles portant les numéros les plus grands sont les derniers ajoutés, et nécessitent en conséquence des versions de Python plus récentes.

- Le protocole 0 est le format originel, humainement lisible. Il est rétrocompatible avec les versions les plus anciennes de Python.

- Le protocole 1 est un ancien format binaire, aussi compatible avec les versions anciennes.

- Protocol version 2 was introduced in Python 2.3. It provides much more efficient pickling of new-style classes. Refer to PEP 307 for information about improvements brought by protocol 2.

- Le protocole 3 a été introduit en Python 3.0. Il gère les objets `bytes`, et ne permet pas la désérialisation par Python 2.x. Il fut le protocole par défaut de Python 3.0 à Python 3.7.

- Le protocole 4 est apparu en Python 3.4. Il prend en charge les objets de très grande taille ainsi que la sérialisation d'une plus grande variété d'objets, et optimise le format. Il est le protocole par défaut depuis Python 3.8. Voir la PEP 3154 pour plus d'informations sur les améliorations apportées par le protocole 4.

- Le protocole 5 a été ajouté en Python 3.8 afin de permettre le transfert des données en marge de la sérialisation elle-même. Il a également accéléré les opérations sur les données à sérialiser. Reportez-vous à la PEP 574 pour les détails relatifs aux améliorations apportées par le protocole 5.

Note

La sérialisation est un problème plus simple que la persistance des données en général. Le module `pickle` lit et écrit des objets fichiers-compatibles, mais ne s'occupe pas du problème de donner un nom à des objets persistants, ni de gérer l'accès par différents processus en parallèle à ces objets. `pickle` se contente de transformer des objets complexes en flux d'octets, et lire ces flux d'octets par la suite pour reconstruire des objets avec la même structure. Si l'on peut bien sûr écrire les flux d'octets dans un fichier, rien n'empêche de les transférer à travers un réseau, ou bien de les stocker dans une base de données. Voir le module `shelve` pour une interface simple qui sérialise et désérialise les objets dans des bases de données de style DBM.

## Interface du module

Pour sérialiser un objet, contenant éventuellement d'autres objets, appelez tout simplement la fonction `dumps()`. La fonction `loads()`, quant à elle, désérialise un flux de données. Pour un contrôle plus fin des opérations de sérialisation ou désérialisation, créez un objet `Pickler` ou `Unpickler`.

Le module `pickle` définit les constantes suivantes :

`pickle.``HIGHEST_PROTOCOL`

  Entier qui donne la version du protocole le plus récent qui soit disponible. Ce nombre peut être passé comme paramètre protocol aux fonctions `dump()` et `dumps()` ainsi qu'au constructeur de la classe `Pickler`.

`pickle.``DEFAULT_PROTOCOL`

  Entier qui donne la version du protocole employé par défaut pour la sérialisation. Il peut être moindre que `HIGHEST_PROTOCOL`. La valeur actuelle est 4, sachant que le protocole correspondant a été introduit en Python 3.4 et n'est pas compatible avec les versions antérieures.

  Modifié dans la version 3.0: Le protocole par défaut est devenu le protocole 3.

  Modifié dans la version 3.8: Le protocole par défaut est devenu le protocole 4.

Le module `pickle` contient quelques fonctions pour faciliter la sérialisation.

`pickle.``dump`(obj, file, protocol=None, *, fix_imports=True, buffer_callback=None)

  Écrit la représentation sérialisée de l'objet obj dans l'objet fichier-compatible file, qui doit être ouvert. Ceci est l'équivalent de `Pickle(file, protocol).dump(obj)`.

  Les arguments file, protocol, fix_imports et buffer_callback sont identiques à ceux du constructeur de la classe `Pickler`.

  Modifié dans la version 3.8: ajout de l'argument buffer_callback.

`pickle.``dumps`(obj, protocol=None, *, fix_imports=True, buffer_callback=None)

  Renvoie la représentation sérialisée de obj sous forme de `bytes`, au lieu de l'écrire dans un fichier.

  Les arguments protocol, fix_imports et buffer_callback sont identiques à ceux du constructeur de la classe `Pickler`.

  Modifié dans la version 3.8: ajout de l'argument buffer_callback.

`pickle.``load`(file, *, fix_imports=True, encoding="ASCII", errors="strict", buffers=None)

  Charge la représentation sérialisée d'un objet depuis l'objet fichier-compatible ouvert file, et renvoie l'objet reconstitué obtenu. Ceci est l'équivalent de `Unpickler(file).load()`.

  La version du protocole utilisée pour la sérialisation est détectée automatiquement, d'où l'absence d'un argument. Les octets situés après la représentation sérialisée de l'objet sont ignorés.

  Les arguments file, fix_imports, encoding, errors, strict et buffers sont identiques à ceux du constructeur de la classe `Unpickler`.

  Modifié dans la version 3.8: Ajout de l'argument buffers.

`pickle.``loads`(data, /, *, fix_imports=True, encoding="ASCII", errors="strict", buffers=None)

  Renvoie l'objet reconstitué à partir de la représentation sérialisée data, qui doit être fournie sous la forme d'un bytes-like object.

  La version du protocole utilisée pour la sérialisation est détectée automatiquement, d'où l'absence d'un argument. Les octets situés après la représentation sérialisée de l'objet sont ignorés.

  Arguments fix_imports, encoding, errors, strict and buffers have the same meaning as in the `Unpickler` constructor.

  Modifié dans la version 3.8: Ajout de l'argument buffers.

Le module `pickle` définit trois types d'exceptions :

exception `pickle.``PickleError`

  Classe mère commune aux autres exceptions de sérialisation. Elle hérite de `Exception`.

exception `pickle.``PicklingError`

  Exception levée lorsqu'un objet impossible à sérialiser est rencontré par un `Pickler`. Elle hérite de `PickleError`.

  Lisez Quels objets sont sérialisables ? pour en savoir plus sur les types d'objets qui peuvent être sérialisés.

exception `pickle.``UnpicklingError`

  Exception levée lorsqu'un flux binaire ne peut pas être désérialisé, par exemple s'il est corrompu ou en cas de violation de la sécurité. Elle hérite de `PickleError`.

  Veuillez noter que d'autres exceptions peuvent être levées durant la désérialisation, comme `AttributeError`, `EOFError`, `ImportError` et `IndexError` (liste non-exhaustive).

Le module `pickle` exporte trois classes : `Pickler`, `Unpickler` et `PickleBuffer`.

class `pickle.``Pickler`(file, protocol=None, *, fix_imports=True, buffer_callback=None)

  Classe d'objets qui implémentent la sérialisation vers un flux binaire.

  L'argument optionnel protocol détermine la version du protocole de sérialisation à employer, entre 0 et `HIGHEST_PROTOCOL`. La valeur par défaut est celle de `DEFAULT_PROTOCOL`. Avec un nombre strictement négatif, c'est `HIGHEST_PROTOCOL` qui est utilisé.

  L'argument file peut être un fichier sur disque ouvert en mode binaire pour l'écriture, une instance de la classe `io.BytesIO`, ou plus généralement un objet quelconque qui possède une méthode `write()` acceptant d'être appelée sur un argument unique de type `bytes`.

  Si fix_imports est vrai et protocol est inférieur ou égal à 2, les noms des modules sont reliés par pickle aux anciens noms qui avaient cours en Python 2, afin que le flux sérialisé soit lisible aussi bien par Python 2 que Python 3.

  Si buffer_callback vaut `None` (comme par défaut), les vues de tampon sont sérialisées dans file avec le reste du flux.

  Dans le cas où le buffer_callback n'est pas `None`, il doit pouvoir être appelé un nombre quelconque de fois avec une vue d'un tampon. S'il renvoie une valeur évaluée comme fausse (telle que `None`), le tampon est considéré en marge de la sérialisation (ou « hors-bande »), sinon il est sérialisé dans le flux binaire.

  Une erreur se produit si buffer_callback vaut autre chose que `None` et protocol est 4 ou inférieur, ou `None`.

  Modifié dans la version 3.8: ajout de l'argument buffer_callback.

  `dump`(obj)

    Écrit la représentation sérialisée de l'objet obj dans le fichier ouvert passé au constructeur.

  `persistent_id`(obj)

    Ne fait rien par défaut. Cette méthode est destinée à être implémentée par une classe fille.

    Si `persistent_id()` renvoie `None`, obj est sérialisé normalement. Toute autre valeur est reprise par le `Pickler` comme ID persistant pour obj. Le sens de cet ID persistant doit être défini par `Unpickler.persistent_load()`. Veuillez noter que la valeur renvoyée par `persistent_id()` ne peut pas porter elle-même d'ID persistant.

    La section Persistance d'objets externes donne des détails et exemples.

  `dispatch_table`

    La table de distribution d'un sérialiseur est un tableau associatif dont les clés sont des classes et les valeurs, des fonctions de réduction. La manière la plus directe de déclarer une fonction de réduction est la fonction `copyreg.pickle()`. Une fonction de réduction prend un unique argument, qui doit être de la classe en question, et obéit à la même interface qu'une méthode `__reduce__()`.

    Lorsqu'un sérialiseur ne possède pas l'attribut `dispatch_table`, comme c'est le cas par défaut, il utilise le tableau global du module `copyreg`. Afin de personnaliser l'opération de sérialisation pour un sérialiseur particulier, on peut affecter à son attribut `dispatch_table` un objet compatible avec les dictionnaires. Une autre possibilité est de définir l'attribut `dispatch_table` dans une classe fille de `Pickler`. Sa valeur sera alors utilisée pour toutes les instances de cette classe fille.

    Voir Tables de distribution pour des exemples d'utilisation.

    Nouveau dans la version 3.3.

  `reducer_override`(obj)

    Réducteur spécial, qui peut se définir dans une classe fille de `Pickler`. Cette méthode doit se conformer à l'interface des méthodes `__reduce__()`. Elle prend en général le pas sur les réducteurs contenus dans l'attribut `dispatch_table`. Cependant, elle peut choisir de renvoyer `NotImplemented` pour que `dispatch_table` soit utilisé à la place.

    Voir Réduction personnalisée pour les types, fonctions et autres objets pour un exemple détaillé.

    Nouveau dans la version 3.8.

  `fast`

    Cet attribut est obsolète. Une valeur vraie (« mode rapide ») désactive la mémorisation des objets au fur et à mesure de leur sérialisation, qui permet habituellement de représenter les doublons par une unique référence. Cette option accélère la sérialisation en évitant des opcodes PUT superflus. Elle ne doit pas être utilisée sur un objet contenant une référence à lui-même, car le `Pickler` entre alors dans une récursion infinie.

    Utilisez plutôt `pickletools.optimize()` pour obtenir des données sérialisées plus compactes.

class `pickle.``Unpickler`(file, *, fix_imports=True, encoding="ASCII", errors="strict", buffers=None)

  Les objets de cette classe sont des désérialiseurs, qui lisent un flux de données pour le convertir en objet.

  Il n'y a nul besoin d'argument protocol. La version du protocole avec lequel sont encodées les données est déterminée automatiquement.

  L'argument file doit posséder trois méthodes qui proviennent de l'interface de `io.BufferedIOBase`. Ce sont : `read()`, prenant un entier, `readinto()`, prenant un tampon, et `readline()`, sans arguments. file peut donc être aussi bien un fichier sur disque ouvert en mode lecture binaire qu'un objet `io.BytesIO`, ou un objet quelconque vérifiant ces critères.

  Les paramètres facultatifs fix_imports, encoding et errors sont dédiés à la compatibilité de la désérialisation avec les flux binaires générés par Python 2. Si fix_imports est vrai, pickle tente de modifier les anciens noms des modules que l'on trouve en Python 2, pour les remplacer par ceux en usage en Python 3. Les paramètres encoding et errors contrôlent la façon de décoder les chaînes de caractères 8 bits. Leurs valeurs par défaut respectives sont `'ASCII'` et `'strict'`. encoding peut être mis à `'bytes'` pour lire des chaînes d'octets en tant que bytes. Il doit être mis à `'latin1'` pour désérialiser des tableaux NumPy ou des instances de `datetime`, `date` et `time` sérialisées par Python 2.

  Si buffers vaut None (comme par défaut), toutes les données nécessaires à la désérialisation doivent être contenues dans le flux binaire. Ceci signifie que l'argument buffer_callback valait None lors de la construction du `Pickler` (ou dans l'appel à `dump()` ou `dumps()`).

  If buffers is not None, it should be an iterable of buffer-enabled objects that is consumed each time the pickle stream references an out-of-band buffer view. Such buffers have been given in order to the buffer_callback of a Pickler object.

  Modifié dans la version 3.8: Ajout de l'argument buffers.

  `load`()

    Lit la représentation sérialisée d'un objet depuis le fichier ouvert passé au constructeur, et reconstitue l'objet qui y est stocké, avec tous les objets qu'il contient. Les octets situés au-delà de la fin de la représentation binaire sont ignorés.

  `persistent_load`(pid)

    Par défaut, cette méthode lève une exception `UnpicklingError`.

    Si elle est définie autrement dans une sous-classe, `persistent_load()` doit renvoyer l'objet correspondant à l'ID persistant pid. Si celui-ci est invalide, elle doit lever une exception `UnpicklingError`.

    La section Persistance d'objets externes donne des détails et exemples.

  `find_class`(module, name)

    Importe module si besoin, et renvoie l'objet du nom name qu'il contient. module et name sont des chaînes de caractères (classe `str`). Contrairement à ce que son nom laisse penser, `find_class()` est également appelée pour trouver les fonctions.

    Les classes filles peuvent redéfinir cette méthode pour restreindre la désérialisation à certains types d'objets ou à d'autres conditions, notamment en vue de réduire les risques de sécurité. Voir Restriction des noms dans l'espace de nommage global pour plus de détails.

    Lève un événement d'audit `pickle.find_class` avec les arguments `module` et `name`.

class `pickle.``PickleBuffer`(buffer)

  Encapsule un objet tampon contenant des données sérialisables. buffer doit être un objet prenant en charge le protocole tampon, comme un objet octet-compatible ou un tableau n-dimensionnel.

  Les objets `PickleBuffer` savent gérer le protocole tampon. Il est donc possible de les passer à d'autres API qui attendent un tampon, comme `memoryview`.

  Les objets `PickleBuffer` ne peuvent être sérialisés qu'avec le protocole 5 ou supérieur. Ils sont susceptibles d'être sérialisés hors-bande.

  Nouveau dans la version 3.8.

  `raw`()

    Renvoie une `memoryview` de l'espace mémoire sous-jacent à ce tampon. La memoryview renvoyée est unidimensionnelle et C-contiguë. Elle a le format `B` (octets sans signe). `BufferError` est levée si le tampon n'est ni C-contigu, ni Fortran-contigu.

  `release`()

    Release the underlying buffer exposed by the PickleBuffer object.

## Quels objets sont sérialisables ?

Les objets des types suivants peuvent être sérialisés :

- `None`, `True`, and `False`;

- integers, floating-point numbers, complex numbers;

- strings, bytes, bytearrays;

- tuples, lists, sets, and dictionaries containing only picklable objects;

- functions (built-in and user-defined) defined at the top level of a module (using `def`, not `lambda`);

- classes defined at the top level of a module;

- instances of such classes whose `__dict__` or the result of calling `__getstate__()` is picklable (see section Sérialisation des instances d'une classe for details).

Si vous essayez de sérialiser un objet qui ne peut pas l'être, une exception de type `PicklingError` est levée. Lorsque cela se produit, il est possible qu'un certain nombre d'octets aient déjà été écrits dans le fichier ou flux. La sérialisation d'une structure de donnée avec de nombreux niveaux d'imbrication peut lever une exception `RecursionError`. Pour augmenter la limite (avec précaution), voir `sys.setrecursionlimit()`.

Note that functions (built-in and user-defined) are pickled by fully qualified name, not by value. 2 This means that only the function name is pickled, along with the name of the module the function is defined in. Neither the function's code, nor any of its function attributes are pickled. Thus the defining module must be importable in the unpickling environment, and the module must contain the named object, otherwise an exception will be raised. 3

Similarly, classes are pickled by fully qualified name, so the same restrictions in the unpickling environment apply. Note that none of the class's code or data is pickled, so in the following example the class attribute `attr` is not restored in the unpickling environment:

    class Foo:
        attr = 'A class attribute'

    picklestring = pickle.dumps(Foo)

These restrictions are why picklable functions and classes must be defined at the top level of a module.

De même, lorsque les instances d'une certaine classe sont sérialisées, seuls les attributs de l'instance sont inclus, mais pas le code de leur classe ni les données qu'elle pourrait contenir. Ceci est intentionnel : vous pouvez corriger des bogues dans une classe ou ajouter des méthodes, et désérialiser malgré tout des objets instanciés avec une version plus ancienne de la classe. Si vous stockez des objets destinés être conservés pendant longtemps, et que leur classe est susceptible de connaître de nombreuses évolutions, il peut s'avérer utile d'associer aux objets un numéro de version afin que des conversions puissent être implémentées dans la méthode `__setstate__()` de la classe.

## Sérialisation des instances d'une classe

Dans cette section sont décrits les mécanismes généraux qui s'offrent à vous pour définir, personnaliser et contrôler la manière dont les instances d'une classe sont sérialisées et désérialisées.

Dans la plupart des cas, il n'y a besoin de rien pour que les instances d'une classe puissent être sérialisées. Par défaut, pickle accède à la classe et aux attributs de l'instance par introspection. Lorsqu'une instance est désérialisée, sa méthode `__init__()` n'est normalement pas appelée. Une nouvelle instance est créée sans être initialisée, et ses attributs sont simplement restaurés à partir des valeurs conservées. En d'autres termes, les opérations sont celles qu'effectue le code suivant :

    def save(obj):
        return (obj.__class__, obj.__dict__)

    def restore(cls, attributes):
        obj = cls.__new__(cls)
        obj.__dict__.update(attributes)
        return obj

Les classes peuvent personnaliser le comportement par défaut en définissant des méthodes spéciales :

`object.``__getnewargs_ex__`()

  Dans les protocoles 2 et suivants, les classes peuvent personnaliser les valeurs passées à la méthode `__new__()` lors de la désérialisation. Elles le font en définissant une méthode `__getnewargs_ex__()` qui renvoie un couple `(args, kwargs)`, où args est un n-uplet des arguments positionnels et kwargs un dictionnaire des arguments nommés qui seront passés à `__new__()` — autrement dit, l'appel sera `classe.__new__(*args, **kwargs)`.

  Définissez cette méthode seulement si la méthode `__new__()` de votre classe demande des arguments nommés. Dans le cas contraire, mieux vaut définir `__getnewargs__()` pour préserver la compatibilité avec les protocoles anciens.

  Modifié dans la version 3.6: `__getnewargs_ex__()` est désormais appelée dans les protocoles 2 et 3.

`object.``__getnewargs__`()

  Comme `__getnewargs_ex__()`, mais ne permet que les arguments positionnels. Cette méthode doit renvoyer le n-uplet `args` des arguments passés à `__new__()` lors de la désérialisation : l'appel sera `classe.__new__(*args)`.

  Si `__getnewargs_ex__()` est définie, elle prend la priorité et `__getnewargs__()` n'est jamais appelée.

  Modifié dans la version 3.6: Auparavant, `__getnewargs__()` était appelée au lieu de `__getnewargs_ex__()` dans les protocoles 2 et 3.

`object.``__getstate__`()

  Classes can further influence how their instances are pickled; if the class defines the method `__getstate__()`, it is called and the returned object is pickled as the contents for the instance, instead of the contents of the instance's dictionary. If the `__getstate__()` method is absent, the instance's `__dict__` is pickled as usual.

`object.``__setstate__`(state)

  Lors de la désérialisation, l'état de l'instance est passé à la méthode `__setstate__()`, si elle est définie (l'objet state n'a pas besoin d'être un dictionnaire). Si elle ne l'est pas, les attributs de l'objet sont tirés de l'état, qui dans ce cas doit être obligatoirement un dictionnaire.

  Note

  Si `__getstate__()` renvoie une valeur fausse, `__setstate__()` ne sera pas appelée à la désérialisation.

Voir Traitement des objets à état pour plus d'informations sur `__getstate__()` et `__setstate__()`.

Note

Lors de la désérialisation, des méthodes comme `__getattr__()`, `__getattribute__()` et `__setattr__()` sont susceptibles d'être appelées sur l'instance. Si ces méthodes reposent sur des invariants internes à l'objet, leur classe doit les initialiser dans la méthode `__new__()`, puisque la méthode `__init__()` n'est pas appelée.

Comme nous le verrons, pickle ne fait pas directement appel aux méthodes ci-dessus. En réalité, elles font partie du protocole de copie, qui implémente la méthode spéciale `__reduce__()`. Ce protocole constitue une interface unifiée pour l'accès aux données nécessaires à la sérialisation comme à la copie 4.

Bien que la méthode `__reduce__()` ouvre davantage de possibilités, elle conduit plus facilement à des erreurs. C'est pourquoi les auteurs de classes sont encouragés à utiliser lorsque c'est possible l'interface de plus haut niveau avec `__getnewargs_ex__()`, `__getstate__()` et `__state__()`. Cependant, il existe des cas où l'on ne peut pas se passer de `__reduce__()`, ou bien elle permet une sérialisation plus efficace.

`object.``__reduce__`()

  Voici l'interface de la méthode `__reduce__()`. Elle ne prend aucun argument et renvoie soit une chaîne de caractères, soit (c'est conseillé) un n-uplet. On appelle souvent l'objet renvoyé « valeur de réduction ».

  If a string is returned, the string should be interpreted as the name of a global variable. It should be the object's local name relative to its module; the pickle module searches the module namespace to determine the object's module. This behaviour is typically useful for singletons.

  Si c'est un n-uplet qui est renvoyé, ses éléments sont interprétés dans l'ordre comme suit. Les deux premiers éléments sont obligatoires, les quatre suivants sont facultatifs et peuvent être simplement omis, ou bien mis à `None`. Les éléments sont, dans l'ordre :

  - Un objet appelable qui sera appelé pour créer l'objet initial.

  - Un n-uplet d'arguments passés à cet objet appelable. Donnez un n-uplet vide si l'objet appelable n'accepte pas d'arguments.

  - L'état de l'objet, qui sera passé à la méthode `__setstate__()` comme vu précédemment. Si la méthode n'existe pas, cet élément doit être un dictionnaire, et ses éléments compléteront l'attribut `__dict__`.

  - Un itérateur (non pas une séquence). Les éléments qu'il fournit sont ajoutés à l'objet un par un avec la méthode `append()`, ou bien plusieurs à la fois avec la méthode `extend()`. Ceci est principalement utile aux les classes héritant de `list`, mais peut aussi servir sur d'autres classes, la seule contrainte étant qu'elles implémentent `append()` et `extend()` avec les bonnes signatures (l'une ou l'autre de ces méthodes est utilisée selon la version du protocole pickle et le nombre d'éléments à ajouter, c'est pourquoi elles doivent être définies toutes les deux).

  - Un itérateur (non pas une séquence). Les éléments qu'il fournit doivent être des couples `(clé, valeur)`. Ils sont ajoutés dans l'objet par affectation aux clés : `objet[clé] = valeur`. Ceci est principalement utile aux classes héritant de `dict`, mais peut servir à d'autres classes à la seule condition qu'elles implémentent la méthode `__setitem__()`.

  - Un objet appelable qui puisse recevoir en arguments l'objet et son état. Ceci permet de redéfinir le processus de reconstruction des attributs pour un objet en particulier, outrepassant la méthode `__setstate__()`. Si cet objet appelable est fourni, `__setstate__()` n'est pas appelée.

    Nouveau dans la version 3.8: ajout du sixième élément.

`object.``__reduce_ex__`(protocol)

  Il est également possible de définir une méthode `__reduce_ex__()`. La seule différence est qu'elle prend la version du protocole en argument. Si elle est définie, elle prend le pas sur `__reduce__()`. De plus, `__reduce__()` devient automatiquement un alias pour sa version étendue. Cette méthode est principalement destinée à renvoyer des valeurs de réduction compatibles avec les versions anciennes de Python.

### Persistance d'objets externes

Pour les besoins de la persistance, `pickle` permet des références à des objets en dehors du flux sérialisé. Ils sont identifiés par un ID persistant. Le protocole 0 requiert que cet ID soit une chaîne de caractères alphanumériques 5. Les suivants autorisent un objet quelconque.

`pickle` délègue la résolution des ID à des méthodes définies par l'utilisateur sur les objets sérialiseurs et désérialiseurs, à savoir `persistent_id()` et `persistent_load()`.

Pour affecter à des objets leurs ID persistants provenant d'une source externe, le sérialiseur doit posséder une méthode `persistent_id()` qui prend un objet et renvoie soit `None`, soit son ID. Si cette méthode renvoie `None`, l'objet est sérialisé de la manière habituelle. Si un ID est renvoyé, sous forme de chaîne de caractères, c'est cette chaîne qui est sérialisée et elle est marquée de manière spéciale pour être reconnue comme un ID persistant.

Pour désérialiser des objets identifiés par un ID externe, un désérialiseur doit posséder une méthode `persistent_load()` qui prend un ID et renvoie l'objet qu'il désigne.

Voici un exemple complet qui montre comment sérialiser des objets externes en leur affectant des ID persistants.

    # Simple example presenting how persistent ID can be used to pickle
    # external objects by reference.

    import pickle
    import sqlite3
    from collections import namedtuple

    # Simple class representing a record in our database.
    MemoRecord = namedtuple("MemoRecord", "key, task")

    class DBPickler(pickle.Pickler):

        def persistent_id(self, obj):
            # Instead of pickling MemoRecord as a regular class instance, we emit a
            # persistent ID.
            if isinstance(obj, MemoRecord):
                # Here, our persistent ID is simply a tuple, containing a tag and a
                # key, which refers to a specific record in the database.
                return ("MemoRecord", obj.key)
            else:
                # If obj does not have a persistent ID, return None. This means obj
                # needs to be pickled as usual.
                return None

    class DBUnpickler(pickle.Unpickler):

        def __init__(self, file, connection):
            super().__init__(file)
            self.connection = connection

        def persistent_load(self, pid):
            # This method is invoked whenever a persistent ID is encountered.
            # Here, pid is the tuple returned by DBPickler.
            cursor = self.connection.cursor()
            type_tag, key_id = pid
            if type_tag == "MemoRecord":
                # Fetch the referenced record from the database and return it.
                cursor.execute("SELECT * FROM memos WHERE key=?", (str(key_id),))
                key, task = cursor.fetchone()
                return MemoRecord(key, task)
            else:
                # Always raises an error if you cannot return the correct object.
                # Otherwise, the unpickler will think None is the object referenced
                # by the persistent ID.
                raise pickle.UnpicklingError("unsupported persistent object")

    def main():
        import io
        import pprint

        # Initialize and populate our database.
        conn = sqlite3.connect(":memory:")
        cursor = conn.cursor()
        cursor.execute("CREATE TABLE memos(key INTEGER PRIMARY KEY, task TEXT)")
        tasks = (
            'give food to fish',
            'prepare group meeting',
            'fight with a zebra',
            )
        for task in tasks:
            cursor.execute("INSERT INTO memos VALUES(NULL, ?)", (task,))

        # Fetch the records to be pickled.
        cursor.execute("SELECT * FROM memos")
        memos = [MemoRecord(key, task) for key, task in cursor]
        # Save the records using our custom DBPickler.
        file = io.BytesIO()
        DBPickler(file).dump(memos)

        print("Pickled records:")
        pprint.pprint(memos)

        # Update a record, just for good measure.
        cursor.execute("UPDATE memos SET task='learn italian' WHERE key=1")

        # Load the records from the pickle data stream.
        file.seek(0)
        memos = DBUnpickler(file, conn).load()

        print("Unpickled records:")
        pprint.pprint(memos)

    if __name__ == '__main__':
        main()

### Tables de distribution

Pour personnaliser la sérialisation d'une classe à un endroit particulier sans affecter le reste du code, on peut créer un sérialiseur avec une table de distribution spécifique.

La table de distribution gérée par le module `copyreg` est disponible sous le nom `copyreg.dispatch_table`. On peut donc utiliser une copie modifiée de `copyreg.dispatch_table` comme table spécifique à un sérialiseur.

Par exemple

    f = io.BytesIO()
    p = pickle.Pickler(f)
    p.dispatch_table = copyreg.dispatch_table.copy()
    p.dispatch_table[SomeClass] = reduce_SomeClass

crée une instance de la classe `pickle.Pickler` avec une table de distribution propre qui traite la classe `SomeClass` de manière spécifique. Le code :

    class MyPickler(pickle.Pickler):
        dispatch_table = copyreg.dispatch_table.copy()
        dispatch_table[SomeClass] = reduce_SomeClass
    f = io.BytesIO()
    p = MyPickler(f)

does the same but all instances of `MyPickler` will by default share the private dispatch table. On the other hand, the code

    copyreg.pickle(SomeClass, reduce_SomeClass)
    f = io.BytesIO()
    p = pickle.Pickler(f)

modifies the global dispatch table shared by all users of the `copyreg` module.

### Traitement des objets à état

L'exemple suivant illustre comment modifier la sérialisation pour une classe. La classe `TextReader` ouvre un fichier de texte, et sa méthode `readline()` renvoie le numéro de la ligne suivante et son contenu chaque fois qu'elle est appelée. Si une instance de `TextReader` est sérialisée, tous les attributs sauf le fichier ouvert sont enregistrés. Lorsque l'instance est désérialisée, le fichier est rouvert et la lecture reprend là où elle s'était arrêtée. Ceci est implémenté à travers les méthodes `__setstate__()` et `__getstate__()`.

    class TextReader:
        """Print and number lines in a text file."""

        def __init__(self, filename):
            self.filename = filename
            self.file = open(filename)
            self.lineno = 0

        def readline(self):
            self.lineno += 1
            line = self.file.readline()
            if not line:
                return None
            if line.endswith('\n'):
                line = line[:-1]
            return "%i: %s" % (self.lineno, line)

        def __getstate__(self):
            # Copy the object's state from self.__dict__ which contains
            # all our instance attributes. Always use the dict.copy()
            # method to avoid modifying the original state.
            state = self.__dict__.copy()
            # Remove the unpicklable entries.
            del state['file']
            return state

        def __setstate__(self, state):
            # Restore instance attributes (i.e., filename and lineno).
            self.__dict__.update(state)
            # Restore the previously opened file's state. To do so, we need to
            # reopen it and read from it until the line count is restored.
            file = open(self.filename)
            for _ in range(self.lineno):
                file.readline()
            # Finally, save the file.
            self.file = file

Voici un exemple d'utilisation :

    >>> reader = TextReader("hello.txt")
    >>> reader.readline()
    '1: Hello world!'
    >>> reader.readline()
    '2: I am line number two.'
    >>> new_reader = pickle.loads(pickle.dumps(reader))
    >>> new_reader.readline()
    '3: Goodbye!'

## Réduction personnalisée pour les types, fonctions et autres objets

Nouveau dans la version 3.8.

Parfois, la simple utilisation de `dispatch_table` n'offre pas assez de flexibilité. On peut vouloir changer la méthode de sérialisation selon d'autres critères que le type de l'objet, ou bien personnaliser la sérialisation des fonctions et des classes.

Dans ces cas, il est possible d'écrire une méthode `reducer_override()` dans une classe fille de `Pickler`. Cette méthode renvoie un n-uplet de réduction arbitraire (voir `__reduce__()`). Elle peut aussi renvoyer `NotImplemented`, auquel cas la méthode habituelle de réduction par table s'applique.

Si `dispatch_table` et `reducer_override()` sont tous les deux définis, `reducer_override()` a la priorité.

Note

Pour des raisons de performance, la méthode `reducer_override()` n'est jamais appelée sur `None`, `True`, `False`, ainsi que les instances exactes (pas dérivées) de `int`, `float`, `bytes`, `str`, `dict`, `set`, `frozenset`, `list` et `tuple`.

Voici un exemple simple qui implémente la sérialisation d'une classe :

    import io
    import pickle

    class MyClass:
        my_attribute = 1

    class MyPickler(pickle.Pickler):
        def reducer_override(self, obj):
            """Custom reducer for MyClass."""
            if getattr(obj, "__name__", None) == "MyClass":
                return type, (obj.__name__, obj.__bases__,
                              {'my_attribute': obj.my_attribute})
            else:
                # For any other object, fallback to usual reduction
                return NotImplemented

    f = io.BytesIO()
    p = MyPickler(f)
    p.dump(MyClass)

    del MyClass

    unpickled_class = pickle.loads(f.getvalue())

    assert isinstance(unpickled_class, type)
    assert unpickled_class.__name__ == "MyClass"
    assert unpickled_class.my_attribute == 1

## Tampons hors-bande

Nouveau dans la version 3.8.

Le module `pickle` est parfois utilisé pour transférer des quantités énormes de données. Il peut devenir important de réduire les copies de mémoire au minimum pour préserver la performance et diminuer l'usage des ressources matérielles. Cependant, dans son contexte courant d'utilisation, le module `pickle` effectue des copies depuis et vers le flux de données pour les besoins de la conversion de structures d'objets semblables à des graphes en flux séquentiels d'octets.

Cette contrainte peut être levée si le producteur (qui implémente les types d'objets à transférer) et le consommateur (qui implémente le système de communication) emploient les possibilités de transfert hors-bande offertes par les protocoles 5 et suivants.

### API des producteurs

Les objets de grande taille à sérialiser doivent posséder une méthode `__reduce_ex__()` qui, lorsqu'elle est appelée pour le protocole 5 ou plus, renvoie un objet `PickleBuffer` au lieu d'un objet `bytes` dès que la taille le justifie.

Les objets `PickleBuffer` ne font que signaler que leur tampon permet le transfert hors-bande. Ils demeurent compatibles avec l'utilisation classique du module `pickle`. Cependant, les consommateurs peuvent aussi choisir d'indiquer à `pickle` qu'ils gèrent eux-mêmes ces tampons.

### API des consommateurs

Un système de communication peut gérer de manière spécifique les objets `PickleBuffer` générés lors de la sérialisation d'un réseau d'objets.

Du côté de l'expéditeur, il faut passer le paramètre buffer_callback à `Pickler` (ou à `dump()` ou `dumps()`). Le buffer_callback sera appelé avec chaque `PickleBuffer` généré lors de la sérialisation du réseau d'objets. Les tampons accumulés par le buffer_callback ne verront pas leurs données copiées dans le flux sérialisé. Il leur sera substitué un marqueur léger.

Du côté du receveur, il faut passer l'argument buffers à `Unpickler` (ou `load()` ou bien `loads()`). buffers est un itérable des tampons passés à buffer_callback. Il doit fournir les tampons dans le même ordre que celui dans lequel ils ont été passés à buffer_callback. Les tampons fournis constituent la source des données qu'attendent les reconstructeurs des objets dont la sérialisation a abouti aux objets `PickleBuffer`.

Entre expéditeur et receveur, le système de communication peut implémenter son propre mécanisme de transfert pour les tampons hors-bande. Parmi les optimisations possibles se trouvent l'utilisation de mémoire partagée et la compression spécifique au type de données.

### Exemple

Voici un exemple trivial où est implémentée une classe fille de `bytearray` capable de sérialisation hors-bande.

    class ZeroCopyByteArray(bytearray):

        def __reduce_ex__(self, protocol):
            if protocol >= 5:
                return type(self)._reconstruct, (PickleBuffer(self),), None
            else:
                # PickleBuffer is forbidden with pickle protocols <= 4.
                return type(self)._reconstruct, (bytearray(self),)

        @classmethod
        def _reconstruct(cls, obj):
            with memoryview(obj) as m:
                # Get a handle over the original buffer object
                obj = m.obj
                if type(obj) is cls:
                    # Original buffer object is a ZeroCopyByteArray, return it
                    # as-is.
                    return obj
                else:
                    return cls(obj)

Lorsqu'il rencontre le bon type, le reconstructeur (la méthode de classe `_reconstruct`) renvoie directement le tampon original. Il s'agit d'une manière simple de simuler l'absence de copie dans cet exemple simpliste.

En tant que consommateur des objets, on peut les sérialiser de la manière classique. La désérialisation conduit alors à une copie.

    b = ZeroCopyByteArray(b"abc")
    data = pickle.dumps(b, protocol=5)
    new_b = pickle.loads(data)
    print(b == new_b)  # True
    print(b is new_b)  # False: a copy was made

Mais en passant un buffer_callback et en donnant les tampons accumulés au désérialiseur, il n'y a plus de copie.

    b = ZeroCopyByteArray(b"abc")
    buffers = []
    data = pickle.dumps(b, protocol=5, buffer_callback=buffers.append)
    new_b = pickle.loads(data, buffers=buffers)
    print(b == new_b)  # True
    print(b is new_b)  # True: no copy was made

Cet exemple est limité par le fait que `bytearray` effectue sa propre allocation de mémoire. Il n'est pas possible de créer un `bytearray` sur la mémoire d'un autre objet. Cependant, certains types de données que l'on trouve dans des bibliothèques externes, comme les tableaux NumPy, n'ont pas cette limitation. Le passage hors-bande permet alors de n'effectuer aucune copie (ou bien de minimiser le nombre de copies) lors du transfert de données d'un système à l'autre ou d'un processus à l'autre.

Voir aussi

PEP 574 — Protocole pickle 5 avec données hors-bande

## Restriction des noms dans l'espace de nommage global

Par défaut, la désérialisation importe toutes les classes ou fonctions que demande le flux de données. Dans bien des cas, ce comportement est inacceptable, puisqu'il permet de faire exécuter du code arbitraire dans l'environnement de désérialisation. Observez le résultat de ce flux de données fait-main lorsqu'il est lu :

    >>> import pickle
    >>> pickle.loads(b"cos\nsystem\n(S'echo hello world'\ntR.")
    hello world
    0

Dans cet exemple, le désérialiseur importe la fonction `os.system()` et l'applique à la chaîne de caractères `"echo hello world"`. C'est inoffensif, mais il n'est pas difficile d'imaginer des variantes qui endommageraient le système.

C'est pour cette raison qu'il s'avère parfois nécessaire de contrôler ce qui peut être désérialisé. Cela est possible en redéfinissant la méthode `Unpickler.find_class()`. Contrairement à ce que son nom laisse penser, `Unpickler.find_class()` est appelée pour tous les noms à chercher dans l'espace de nommage global, ce qui inclut les classes mais aussi les fonctions. Par ce biais, il est possible d'interdire complètement la résolution des noms globaux ou de la restreindre à un sous-ensemble que l'on considère sûr.

Voici un exemple de désérialiseur qui permet seulement la désérialisation d'un petit nombre de classes sûres du module `builtins`.

    import builtins
    import io
    import pickle

    safe_builtins = {
        'range',
        'complex',
        'set',
        'frozenset',
        'slice',
    }

    class RestrictedUnpickler(pickle.Unpickler):

        def find_class(self, module, name):
            # Only allow safe classes from builtins.
            if module == "builtins" and name in safe_builtins:
                return getattr(builtins, name)
            # Forbid everything else.
            raise pickle.UnpicklingError("global '%s.%s' is forbidden" %
                                         (module, name))

    def restricted_loads(s):
        """Helper function analogous to pickle.loads()."""
        return RestrictedUnpickler(io.BytesIO(s)).load()

A sample usage of our unpickler working as intended:

    >>> restricted_loads(pickle.dumps([1, 2, range(15)]))
    [1, 2, range(0, 15)]
    >>> restricted_loads(b"cos\nsystem\n(S'echo hello world'\ntR.")
    Traceback (most recent call last):
      ...
    pickle.UnpicklingError: global 'os.system' is forbidden
    >>> restricted_loads(b'cbuiltins\neval\n'
    ...                  b'(S\'getattr(__import__("os"), "system")'
    ...                  b'("echo hello world")\'\ntR.')
    Traceback (most recent call last):
      ...
    pickle.UnpicklingError: global 'builtins.eval' is forbidden

Comme le montre l'exemple, il faut faire attention aux objets que l'on autorise à être désérialisés. Si la sécurité est une priorité, il peut être sage de se tourner vers des alternatives comme l'API du module `xmlrpc.client`, ou des bibliothèques tierces.

## Performances

Recent versions of the pickle protocol (from protocol 2 and upwards) feature efficient binary encodings for several common features and built-in types. Also, the `pickle` module has a transparent optimizer written in C.

## Exemples

Dans les cas les plus simples, utilisez les fonctions `dump()` et `load()`.

    import pickle

    # An arbitrary collection of objects supported by pickle.
    data = {
        'a': [1, 2.0, 3+4j],
        'b': ("character string", b"byte string"),
        'c': {None, True, False}
    }

    with open('data.pickle', 'wb') as f:
        # Pickle the 'data' dictionary using the highest protocol available.
        pickle.dump(data, f, pickle.HIGHEST_PROTOCOL)

Le code suivant lit les données qui viennent d'être sérialisées :

    import pickle

    with open('data.pickle', 'rb') as f:
        # The protocol version used is detected automatically, so we do not
        # have to specify it.
        data = pickle.load(f)

Voir aussi

Module `copyreg`

  Enregistre les fonctions de sérialisation pour les types définis par l'utilisateur.

Module `pickletools`

  Outils pour travailler sur les données sérialisées et les analyser.

Module `shelve`

  Bases de données indexées (module fondé sur `pickle`).

Module `copy`

  Copie superficielle ou récursive d'objets.

Module `marshal`

  Sérialisation haute-performance des types natifs.

Notes

1

  À ne pas confondre avec ce que fait le module `marshal`.

2

  C'est la raison pour laquelle les fonctions `lambda` ne peuvent pas être sérialisées : elles partagent toutes le même nom, à savoir `<lambda>`.

3

  L'exception levée est généralement de type `ImportError` ou `AttributeError`, mais ce n'est pas systématique.

4

  Le module `copy` fait appel à ce protocole pour les opérations de copie superficielle comme récursive.

5

  The limitation on alphanumeric characters is due to the fact that persistent IDs in protocol 0 are delimited by the newline character. Therefore if any kind of newline characters occurs in persistent IDs, the resulting pickled data will become unreadable.