1. Étendre Python en C ou C++

Il est relativement facile d'ajouter de nouveaux modules à Python, si vous savez programmer en C. Ces <modules d'extension> extension modules permettent deux choses qui ne sont pas possible directement en Python: Elles peuvent définir de nouveaux types natifs, et peuvent appeler des fonctions de bibliothèques C ou appels systèmes.

Pour gérer les extensions, l'API Python (Application Programmer Interface) définit un ensemble de fonctions, macros et variables qui donnent accès à la plupart des aspects du système d'exécution de Python. L'API Python est incorporée dans un fichier source C en incluant l'en-tête "Python.h".

La compilation d'un module d'extension dépend de l'usage prévu et de la configuration du système, plus de détails peuvent être trouvés dans les chapitres suivants.

Note

L'interface d'extension C est spécifique à CPython, et les modules d'extension ne fonctionne pas sur les autres implémentations de Python. Dans de nombreux cas, il est possible d'éviter la rédaction des extensions en C et ainsi préserver la portabilité vers d'autres implémentations. Par exemple, si vous devez appeler une fonction de la bibliothèque C ou faire un appel système, vous devriez envisager d'utiliser le module ctypes ou d'utiliser la bibliothèque cffi plutôt que d'écrire du code C sur mesure. Ces modules vous permettent d'écrire du code Python s'interfaçant avec le code C et sont plus portables entre les implémentations de Python que l'écriture et la compilation d'une d'extension C.

1.1. Un exemple simple

Créons un module d'extension appelé spam (la nourriture préférée de fans des Monty Python ...) et disons que nous voulons créer une interface Python à la fonction de la bibliothèque C system() 1. Cette fonction prend une chaîne de caractères terminée par NULL comme argument et renvoie un entier. Nous voulons que cette fonction soit appelable à partir de Python comme suit :

>>> import spam
>>> status = spam.system("ls -l")

Commencez par créer un fichier spammodule.c. (Historiquement, si un module se nomme spam, le fichier C contenant son implémentation est appelé spammodule.c. Si le nom du module est très long, comme spammify, le nom du module peut être juste spammify.c.)

Les deux premières lignes de notre fichier peuvent être :

#define PY_SSIZE_T_CLEAN
#include <Python.h>

qui récupère l'API Python (vous pouvez ajouter un commentaire décrivant le but du module et un avis de droit d'auteur si vous le souhaitez).

Note

Python pouvant définir certaines définitions pré-processeur qui affectent les têtes standard sur certains systèmes, vous devez inclure Python.h avant les en-têtes standards.

Il est recommandé de toujours définir PY_SSIZE_T_CLEAN avant d'inclure Python.h. Lisez Extraire des paramètres dans des fonctions d'extension pour avoir une description de cette macro.

Tous les symboles exposés par Python.h sont préfixés de Py ou PY, sauf ceux qui sont définis dans les en-têtes standard. Pour le confort, et comme ils sont largement utilisés par l'interpréteur Python, "Python.h" inclut lui même quelques d'en-têtes standard : <stdio.h>, <string.h>, <errno.h> et <stdlib.h>. Si ce dernier n'existe pas sur votre système, il déclare les fonctions malloc(), free() et realloc() directement.

La prochaine chose que nous ajoutons à notre fichier de module est la fonction C qui sera appelée lorsque l'expression Python spam.system(chaîne) sera évaluée (nous verrons bientôt comment elle finit par être appelée) :

static PyObject *
spam_system(PyObject *self, PyObject *args)
{
    const char *command;
    int sts;

    if (!PyArg_ParseTuple(args, "s", &command))
        return NULL;
    sts = system(command);
    return PyLong_FromLong(sts);
}

Il y a une correspondance directe de la liste des arguments en Python (par exemple, l'expression "ls -l") aux arguments passés à la fonction C. La fonction C a toujours deux arguments, appelés par convention self et args.

Pour les fonctions au niveau du module, l'argument self pointe sur l'objet module, pour une méthode, il pointe sur l'instance de l'objet.

L'argument args sera un pointeur vers un tuple Python contenant les arguments. Chaque élément du tuple correspond à un argument dans la liste des arguments de l'appel. Les arguments sont des objets Python --- afin d'en faire quelque chose dans notre fonction C, nous devons les convertir en valeurs C. La fonction PyArg_ParseTuple() de l'API Python vérifie les types des arguments et les convertit en valeurs C. Elle utilise un modèle sous forme de chaîne pour déterminer les types requis des arguments ainsi que les types de variables C dans lequel stocker les valeurs converties. Nous en verront plus, plus tard.

PyArg_ParseTuple() renvoie vrai (pas zéro) si tous les arguments ont le bon type et que ses composants ont été stockés dans les variables dont les adresses ont été données en entrée. Il renvoie faux (zéro) si une liste d'arguments invalide a été passée. Dans ce dernier cas, elle lève également une exception appropriée de sorte que la fonction d'appel puisse renvoyer NULL immédiatement (comme nous l'avons vu dans l'exemple).

1.2. Intermezzo: Les erreurs et exceptions

An important convention throughout the Python interpreter is the following: when a function fails, it should set an exception condition and return an error value (usually a NULL pointer). Exceptions are stored in a static global variable inside the interpreter; if this variable is NULL no exception has occurred. A second global variable stores the "associated value" of the exception (the second argument to raise). A third variable contains the stack traceback in case the error originated in Python code. These three variables are the C equivalents of the result in Python of sys.exc_info() (see the section on module sys in the Python Library Reference). It is important to know about them to understand how errors are passed around.

L'API Python définit un certain nombre de fonctions pour créer différents types d'exceptions.

La plus courante est PyErr_SetString(). Ses arguments sont un objet exception et une chaîne C. L'objet exception est généralement un objet prédéfini comme PyExc_ZeroDivisionError. La chaîne C indique la cause de l'erreur et est convertie en une chaîne Python puis stockée en tant que "valeur associée" à l'exception.

Une autre fonction utile est PyErr_SetFromErrno(), qui construit une exception à partir de la valeur de la variable globale errno. La fonction la plus générale est PyErr_SetObject(), qui prend deux arguments: l'exception et sa valeur associée. Vous ne devez pas appliquer Py_INCREF() aux objets transmis à ces fonctions.

Vous pouvez tester de manière non destructive si une exception a été levée avec PyErr_Occurred(). Cela renvoie l'objet exception actuel, ou NULL si aucune exception n'a eu lieu. Cependant, vous ne devriez pas avoir besoin d'appeler PyErr_Occurred() pour voir si une erreur est survenue durant l'appel d'une fonction, puisque vous devriez être en mesure de le déterminer à partir de la valeur renvoyée.

When a function f that calls another function g detects that the latter fails, f should itself return an error value (usually NULL or -1). It should not call one of the PyErr_*() functions --- one has already been called by g. f's caller is then supposed to also return an error indication to its caller, again without calling PyErr_*(), and so on --- the most detailed cause of the error was already reported by the function that first detected it. Once the error reaches the Python interpreter's main loop, this aborts the currently executing Python code and tries to find an exception handler specified by the Python programmer.

(Il y a des situations où un module peut effectivement donner un message d'erreur plus détaillé en appelant une autre fonction PyErr_*(), dans de tels cas, il est tout à fait possible de le faire. Cependant, ce n'est généralement pas nécessaire, et peut amener à perdre des informations sur la cause de l'erreur: la plupart des opérations peuvent échouer pour tout un tas de raisons).

Pour ignorer une exception qui aurait été émise lors d'un appel de fonction qui aurait échoué, l'exception doit être retirée explicitement en appelant PyErr_Clear(). Le seul cas pour lequel du code C devrait appeler PyErr_Clear() est lorsqu'il ne veut pas passer l'erreur à l'interpréteur, mais souhaite la gérer lui-même (peut-être en essayant quelque chose d'autre, ou en prétendant que rien n'a mal tourné).

Chaque échec de malloc() doit être transformé en une exception --- l'appelant direct de malloc() (ou realloc()) doit appeler PyErr_NoMemory() et prendre l'initiative de renvoyer une valeur d'erreur. Toutes les fonctions construisant des objets (tels que PyLong_FromLong()) le font déjà, donc cette note ne concerne que ceux qui appellent malloc() directement.

Notez également que, à l'exception notable de PyArg_ParseTuple() et compagnie, les fonctions qui renvoient leur statut sous forme d'entier donnent généralement une valeur positive ou zéro en cas de succès et -1 en cas d'échec, comme les appels du système Unix.

Enfin, lorsque vous renvoyez un code d'erreur, n'oubliez pas faire un brin de nettoyage (en appelant Py_XDECREF() ou Py_DECREF() avec les objets que vous auriez déjà créés) !

Le choix de l'exception à lever vous incombe. Il existe des objets C correspondant à chaque exception Python, tel que PyExc_ZeroDivisionError, que vous pouvez utiliser directement. Choisissez judicieusement vos exceptions, typiquement n'utilisez pas PyExc_TypeError pour indiquer qu'un fichier n'a pas pu être ouvert (qui devrait probablement être PyExc_IOError). Si quelque chose ne va pas avec la liste des arguments, la fonction PyArg_ParseTuple() lève habituellement une exception PyExc_TypeError. Mais si vous avez un argument dont la valeur doit être dans un intervalle particulier ou qui doit satisfaire d'autres conditions, PyExc_ValueError sera plus appropriée.

Vous pouvez également créer une exception spécifique à votre module. Pour cela, déclarez simplement une variable statique au début de votre fichier :

static PyObject *SpamError;

et initialisez-la dans la fonction d'initialisation de votre module (PyInit_spam()) avec un objet exception :

PyMODINIT_FUNC
PyInit_spam(void)
{
    PyObject *m;

    m = PyModule_Create(&spammodule);
    if (m == NULL)
        return NULL;

    SpamError = PyErr_NewException("spam.error", NULL, NULL);
    Py_XINCREF(SpamError);
    if (PyModule_AddObject(m, "error", SpamError) < 0) {
        Py_XDECREF(SpamError);
        Py_CLEAR(SpamError);
        Py_DECREF(m);
        return NULL;
    }

    return m;
}

Notez que le nom de l'exception en Python est spam.error. La fonction PyErr_NewException() peut créer une classe héritant de Exception (à moins qu'une autre classe ne lui soit fournie à la place de NULL), voir Exceptions natives.

Notez également que la variable SpamError contient une référence à la nouvelle classe créée; ceci est intentionnel! Comme l'exception peut être retirée du module par un code externe, une référence à la classe est nécessaire pour assurer qu'il ne sera pas rejeté, causant SpamError à devenir un pointeur défaillant. S'il devenait un pointeur défaillant, le C code qui lève l'exception peut engendrer un rejet central ou des effets secondaires inattendus.

Nous traiterons de l'utilisation de PyMODINIT_FUNC comme un type de retour de fonction plus tard dans cette section.

L'exception spam.error peut être levée dans votre module d'extension en appelant PyErr_SetString() comme montré ci-dessous :

static PyObject *
spam_system(PyObject *self, PyObject *args)
{
    const char *command;
    int sts;

    if (!PyArg_ParseTuple(args, "s", &command))
        return NULL;
    sts = system(command);
    if (sts < 0) {
        PyErr_SetString(SpamError, "System command failed");
        return NULL;
    }
    return PyLong_FromLong(sts);
}

1.3. Retour vers l'exemple

En revenant vers notre fonction exemple, vous devriez maintenant être capable de comprendre cette affirmation :

if (!PyArg_ParseTuple(args, "s", &command))
    return NULL;

Elle renvoie NULL (l'indicateur d'erreur pour les fonctions renvoyant des pointeurs d'objet) si une erreur est détectée dans la liste des arguments, se fiant à l'exception définie par PyArg_ParseTuple(). Autrement, la valeur chaîne de l'argument a été copiée dans la variable locale command. Il s'agit d'une attribution de pointeur et vous n'êtes pas supposés modifier la chaîne vers laquelle il pointe (donc en C Standard, la variable command doit être clairement déclarée comme const char *command).

La prochaine instruction est un appel à la fonction Unix system(), en lui passant la chaîne que nous venons d'obtenir à partir de PyArg_ParseTuple() :

sts = system(command);

Notre fonction spam.system() doit renvoyer la valeur de sts comme un objet Python. Cela est effectué par l'utilisation de la fonction PyLong_FromLong().

return PyLong_FromLong(sts);

Dans ce cas, elle renverra un objet entier. (Oui, même les entiers sont des objets dans le tas en Python!)

Si vous avez une fonction C qui ne renvoie aucun argument utile (une fonction renvoyant void), la fonction Python correspondante doit renvoyer None. Vous aurez besoin de cette locution pour cela (qui est implémentée par la macro Py_RETURN_NONE) :

Py_INCREF(Py_None);
return Py_None;

Py_None est la dénomination en C pour l'objet spécial Python None. C'est un authentique objet Python plutôt qu'un pointeur NULL, qui signifie qu'une erreur est survenue, dans la plupart des situations, comme nous l'avons vu.

1.4. La fonction d'initialisation et le tableau des méthodes du module

Nous avons promis de montrer comment spam_system() est appelée depuis les programmes Python. D'abord, nous avons besoin d'avoir son nom et son adresse dans un « tableau des méthodes » :

static PyMethodDef SpamMethods[] = {
    ...
    {"system",  spam_system, METH_VARARGS,
     "Execute a shell command."},
    ...
    {NULL, NULL, 0, NULL}        /* Sentinel */
};

Notez la troisième entrée (METH_VARARGS). C'est un indicateur du type de convention à utiliser pour la fonction C, à destination de l'interpréteur. Il doit valoir normalement METH_VARARGS ou METH_VARARGS | METH_KEYWORDS ; la valeur 0 indique qu'une variante obsolète de PyArg_ParseTuple() est utilisée.

Si seulement METH_VARARGS est utilisé, la fonction s'attend à ce que les paramètres Python soient passés comme un n-uplet que l'on peut analyser via PyArg_ParseTuple() ; des informations supplémentaires sont fournies plus bas.

Le bit METH_KEYWORDS peut être mis à un dans le troisième champ si des arguments par mot-clés doivent être passés à la fonction. Dans ce cas, la fonction C doit accepter un troisième paramètre PyObject * qui est un dictionnaire des mots-clés. Utilisez PyArg_ParseTupleAndKeywords() pour analyser les arguments d'une telle fonction.

Le tableau des méthodes doit être référencé dans la structure de définition du module :

static struct PyModuleDef spammodule = {
    PyModuleDef_HEAD_INIT,
    "spam",   /* name of module */
    spam_doc, /* module documentation, may be NULL */
    -1,       /* size of per-interpreter state of the module,
                 or -1 if the module keeps state in global variables. */
    SpamMethods
};

Cette structure, à son tour, doit être transmise à l'interpréteur dans la fonction d'initialisation du module. La fonction d'initialisation doit être nommée PyInit_name(), où nom est le nom du module, et doit être le seul élément non static défini dans le fichier du module :

PyMODINIT_FUNC
PyInit_spam(void)
{
    return PyModule_Create(&spammodule);
}

Notez que PyMODINIT_FUNC déclare la fonction comme renvoyant un objet de type PyObject *, et déclare également toute déclaration de liaison spéciale requise par la plate-forme, et pour le C++ déclare la fonction comme un C extern.

Lorsque le programme Python importe le module spam pour la première fois, PyInit_spam() est appelé. (Voir ci-dessous pour les commentaires sur l'intégration en Python.) Il appelle PyModule_Create(), qui renvoie un objet module, et insère des objets fonction intégrés dans le module nouvellement créé en se basant sur la table (un tableau de structures PyMethodDef) trouvée dans la définition du module. PyModule_Create() renvoie un pointeur vers l'objet module qu'il crée. Il peut s'interrompre avec une erreur fatale pour certaines erreurs, ou renvoyer NULL si le module n'a pas pu être initialisé de manière satisfaisante. La fonction *init* doit renvoyer l'objet module à son appelant, afin qu'il soit ensuite inséré dans ``sys.modules`.

Lors de l'intégration de Python, la fonction PyInit_spam() n'est pas appelée automatiquement, sauf s'il y a une entrée dans la table PyImport_Inittab. Pour ajouter le module à la table d'initialisation, utilisez PyImport_AppendInittab(), suivi éventuellement d'une importation du module :

int
main(int argc, char *argv[])
{
    wchar_t *program = Py_DecodeLocale(argv[0], NULL);
    if (program == NULL) {
        fprintf(stderr, "Fatal error: cannot decode argv[0]\n");
        exit(1);
    }

    /* Add a built-in module, before Py_Initialize */
    if (PyImport_AppendInittab("spam", PyInit_spam) == -1) {
        fprintf(stderr, "Error: could not extend in-built modules table\n");
        exit(1);
    }

    /* Pass argv[0] to the Python interpreter */
    Py_SetProgramName(program);

    /* Initialize the Python interpreter.  Required.
       If this step fails, it will be a fatal error. */
    Py_Initialize();

    /* Optionally import the module; alternatively,
       import can be deferred until the embedded script
       imports it. */
    PyObject *pmodule = PyImport_ImportModule("spam");
    if (!pmodule) {
        PyErr_Print();
        fprintf(stderr, "Error: could not import module 'spam'\n");
    }

    ...

    PyMem_RawFree(program);
    return 0;
}

Note

Supprimer des entrées de sys.modules ou importer des modules compilés dans plusieurs interpréteurs au sein d'un processus (ou suivre un fork() sans l'intervention d'un exec()) peut créer des problèmes pour certains modules d'extension. Les auteurs de modules d'extension doivent faire preuve de prudence lorsqu'ils initialisent des structures de données internes.

Un exemple de module plus substantiel est inclus dans la distribution des sources Python sous le nom Modules/xxmodule.c. Ce fichier peut être utilisé comme modèle ou simplement lu comme exemple.

Note

Contrairement à notre exemple de spam, xxmodule utilise une initialisation multi-phase (nouveau en Python 3.5), où une structure PyModuleDef est renvoyée à partir de PyInit_spam, et la création du module est laissée au mécanisme d'importation. Pour plus de détails sur l'initialisation multi-phase, voir PEP 489.

1.5. Compilation et liaison

There are two more things to do before you can use your new extension: compiling and linking it with the Python system. If you use dynamic loading, the details may depend on the style of dynamic loading your system uses; see the chapters about building extension modules (chapter Construire des extensions C et C++) and additional information that pertains only to building on Windows (chapter Construire des extensions C et C++ sur Windows) for more information about this.

If you can't use dynamic loading, or if you want to make your module a permanent part of the Python interpreter, you will have to change the configuration setup and rebuild the interpreter. Luckily, this is very simple on Unix: just place your file (spammodule.c for example) in the Modules/ directory of an unpacked source distribution, add a line to the file Modules/Setup.local describing your file:

spam spammodule.o

and rebuild the interpreter by running make in the toplevel directory. You can also run make in the Modules/ subdirectory, but then you must first rebuild Makefile there by running 'make Makefile'. (This is necessary each time you change the Setup file.)

If your module requires additional libraries to link with, these can be listed on the line in the configuration file as well, for instance:

spam spammodule.o -lX11

1.6. Appeler des fonctions Python en C

So far we have concentrated on making C functions callable from Python. The reverse is also useful: calling Python functions from C. This is especially the case for libraries that support so-called "callback" functions. If a C interface makes use of callbacks, the equivalent Python often needs to provide a callback mechanism to the Python programmer; the implementation will require calling the Python callback functions from a C callback. Other uses are also imaginable.

Fortunately, the Python interpreter is easily called recursively, and there is a standard interface to call a Python function. (I won't dwell on how to call the Python parser with a particular string as input --- if you're interested, have a look at the implementation of the -c command line option in Modules/main.c from the Python source code.)

Calling a Python function is easy. First, the Python program must somehow pass you the Python function object. You should provide a function (or some other interface) to do this. When this function is called, save a pointer to the Python function object (be careful to Py_INCREF() it!) in a global variable --- or wherever you see fit. For example, the following function might be part of a module definition:

static PyObject *my_callback = NULL;

static PyObject *
my_set_callback(PyObject *dummy, PyObject *args)
{
    PyObject *result = NULL;
    PyObject *temp;

    if (PyArg_ParseTuple(args, "O:set_callback", &temp)) {
        if (!PyCallable_Check(temp)) {
            PyErr_SetString(PyExc_TypeError, "parameter must be callable");
            return NULL;
        }
        Py_XINCREF(temp);         /* Add a reference to new callback */
        Py_XDECREF(my_callback);  /* Dispose of previous callback */
        my_callback = temp;       /* Remember new callback */
        /* Boilerplate to return "None" */
        Py_INCREF(Py_None);
        result = Py_None;
    }
    return result;
}

Cette fonction doit être déclarée en utilisant le drapeau METH_VARARGS ; ceci est décrit dans la section La fonction d'initialisation et le tableau des méthodes du module. La fonction PyArg_ParseTuple() et ses arguments sont documentés dans la section Extraire des paramètres dans des fonctions d'extension.

Les macros Py_XINCREF() et Py_XDECREF() incrémentent/décrémentent le compteur des références d'un objet et sont sûres quant à la présence de pointeurs NULL (mais notez que temp ne sera pas NULL dans ce contexte). Plus d'informations à ce sujet dans la section Compteurs de références.

Later, when it is time to call the function, you call the C function PyObject_CallObject(). This function has two arguments, both pointers to arbitrary Python objects: the Python function, and the argument list. The argument list must always be a tuple object, whose length is the number of arguments. To call the Python function with no arguments, pass in NULL, or an empty tuple; to call it with one argument, pass a singleton tuple. Py_BuildValue() returns a tuple when its format string consists of zero or more format codes between parentheses. For example:

int arg;
PyObject *arglist;
PyObject *result;
...
arg = 123;
...
/* Time to call the callback */
arglist = Py_BuildValue("(i)", arg);
result = PyObject_CallObject(my_callback, arglist);
Py_DECREF(arglist);

PyObject_CallObject() returns a Python object pointer: this is the return value of the Python function. PyObject_CallObject() is "reference-count-neutral" with respect to its arguments. In the example a new tuple was created to serve as the argument list, which is Py_DECREF()-ed immediately after the PyObject_CallObject() call.

The return value of PyObject_CallObject() is "new": either it is a brand new object, or it is an existing object whose reference count has been incremented. So, unless you want to save it in a global variable, you should somehow Py_DECREF() the result, even (especially!) if you are not interested in its value.

Mais avant de le faire, il est important de vérifier que la valeur renvoyée n'est pas NULL. Si c'est le cas, la fonction Python s'est terminée par la levée d'une exception. Si le code C qui a appelé PyObject_CallObject() est appelé depuis Python, il devrait maintenant renvoyer une indication d'erreur à son appelant Python, afin que l'interpréteur puisse afficher la pile d'appels, ou que le code Python appelant puisse gérer l'exception. Si cela n'est pas possible ou souhaitable, l'exception doit être effacée en appelant PyErr_Clear(). Par exemple :

if (result == NULL)
    return NULL; /* Pass error back */
...use result...
Py_DECREF(result);

Selon l'interface souhaitée pour la fonction de rappel Python, vous devrez peut-être aussi fournir une liste d'arguments à PyObject_CallObject(). Dans certains cas, la liste d'arguments est également fournie par le programme Python, par l'intermédiaire de la même interface qui a spécifié la fonction de rappel. Elle peut alors être sauvegardée et utilisée de la même manière que l'objet fonction. Dans d'autres cas, vous pouvez avoir à construire un nouveau n-uplet à passer comme liste d'arguments. La façon la plus simple de faire cela est d'appeler Py_BuildValue(). Par exemple, si vous voulez passer un code d'événement intégral, vous pouvez utiliser le code suivant :

PyObject *arglist;
...
arglist = Py_BuildValue("(l)", eventcode);
result = PyObject_CallObject(my_callback, arglist);
Py_DECREF(arglist);
if (result == NULL)
    return NULL; /* Pass error back */
/* Here maybe use the result */
Py_DECREF(result);

Note the placement of Py_DECREF(arglist) immediately after the call, before the error check! Also note that strictly speaking this code is not complete: Py_BuildValue() may run out of memory, and this should be checked.

Vous pouvez également appeler une fonction avec des arguments nommés en utilisant PyObject_Call(), qui accepte les arguments et les arguments nommés. Comme dans l'exemple ci-dessus, nous utilisons Py_BuildValue() pour construire le dictionnaire. :

PyObject *dict;
...
dict = Py_BuildValue("{s:i}", "name", val);
result = PyObject_Call(my_callback, NULL, dict);
Py_DECREF(dict);
if (result == NULL)
    return NULL; /* Pass error back */
/* Here maybe use the result */
Py_DECREF(result);

1.7. Extraire des paramètres dans des fonctions d'extension

La fonction PyArg_ParseTuple() est déclarée ainsi :

int PyArg_ParseTuple(PyObject *arg, const char *format, ...);

The arg argument must be a tuple object containing an argument list passed from Python to a C function. The format argument must be a format string, whose syntax is explained in Analyse des arguments et construction des valeurs in the Python/C API Reference Manual. The remaining arguments must be addresses of variables whose type is determined by the format string.

Note that while PyArg_ParseTuple() checks that the Python arguments have the required types, it cannot check the validity of the addresses of C variables passed to the call: if you make mistakes there, your code will probably crash or at least overwrite random bits in memory. So be careful!

Notez que n'importe quelles références sur un objet Python qui sont données à l'appelant sont des références empruntées ; ne décrémentez pas leur compteur de références !

Quelques exemples d'appels :

#define PY_SSIZE_T_CLEAN  /* Make "s#" use Py_ssize_t rather than int. */
#include <Python.h>

int ok;
int i, j;
long k, l;
const char *s;
Py_ssize_t size;

ok = PyArg_ParseTuple(args, ""); /* No arguments */
    /* Python call: f() */

ok = PyArg_ParseTuple(args, "s", &s); /* A string */
    /* Possible Python call: f('whoops!') */

ok = PyArg_ParseTuple(args, "lls", &k, &l, &s); /* Two longs and a string */
    /* Possible Python call: f(1, 2, 'three') */

ok = PyArg_ParseTuple(args, "(ii)s#", &i, &j, &s, &size);
    /* A pair of ints and a string, whose size is also returned */
    /* Possible Python call: f((1, 2), 'three') */

{
    const char *file;
    const char *mode = "r";
    int bufsize = 0;
    ok = PyArg_ParseTuple(args, "s|si", &file, &mode, &bufsize);
    /* A string, and optionally another string and an integer */
    /* Possible Python calls:
       f('spam')
       f('spam', 'w')
       f('spam', 'wb', 100000) */
}

{
    int left, top, right, bottom, h, v;
    ok = PyArg_ParseTuple(args, "((ii)(ii))(ii)",
             &left, &top, &right, &bottom, &h, &v);
    /* A rectangle and a point */
    /* Possible Python call:
       f(((0, 0), (400, 300)), (10, 10)) */
}

{
    Py_complex c;
    ok = PyArg_ParseTuple(args, "D:myfunction", &c);
    /* a complex, also providing a function name for errors */
    /* Possible Python call: myfunction(1+2j) */
}

1.8. Paramètres nommés pour des fonctions d'extension

La fonction PyArg_ParseTupleAndKeywords() est déclarée ainsi :

int PyArg_ParseTupleAndKeywords(PyObject *arg, PyObject *kwdict,
                                const char *format, char *kwlist[], ...);

Les paramètres arg et format sont identiques à ceux de la fonction PyArg_ParseTuple(). Le paramètre kwdict est le dictionnaire de mots-clés reçu comme troisième paramètre du runtime Python. Le paramètre kwlist est une liste de chaînes de caractères terminée par NULL qui identifie les paramètres ; les noms sont mis en correspondance, de gauche à droite, avec les informations de type de format. En cas de succès du processus, PyArg_ParseTupleAndKeywords() renvoie vrai, sinon il renvoie faux et lève une exception appropriée.

Note

Les n-uplets imbriqués ne peuvent pas être traités lorsqu'on utilise des arguments de type mot-clé ! Ceux-ci doivent apparaître dans dans kwlist, dans le cas contraire une exception TypeError est levée.

Voici un exemple de module qui utilise des mots-clés, basé sur un exemple de Geoff Philbrick (philbrick@hks.com) :

#define PY_SSIZE_T_CLEAN  /* Make "s#" use Py_ssize_t rather than int. */
#include <Python.h>

static PyObject *
keywdarg_parrot(PyObject *self, PyObject *args, PyObject *keywds)
{
    int voltage;
    const char *state = "a stiff";
    const char *action = "voom";
    const char *type = "Norwegian Blue";

    static char *kwlist[] = {"voltage", "state", "action", "type", NULL};

    if (!PyArg_ParseTupleAndKeywords(args, keywds, "i|sss", kwlist,
                                     &voltage, &state, &action, &type))
        return NULL;

    printf("-- This parrot wouldn't %s if you put %i Volts through it.\n",
           action, voltage);
    printf("-- Lovely plumage, the %s -- It's %s!\n", type, state);

    Py_RETURN_NONE;
}

static PyMethodDef keywdarg_methods[] = {
    /* The cast of the function is necessary since PyCFunction values
     * only take two PyObject* parameters, and keywdarg_parrot() takes
     * three.
     */
    {"parrot", (PyCFunction)(void(*)(void))keywdarg_parrot, METH_VARARGS | METH_KEYWORDS,
     "Print a lovely skit to standard output."},
    {NULL, NULL, 0, NULL}   /* sentinel */
};

static struct PyModuleDef keywdargmodule = {
    PyModuleDef_HEAD_INIT,
    "keywdarg",
    NULL,
    -1,
    keywdarg_methods
};

PyMODINIT_FUNC
PyInit_keywdarg(void)
{
    return PyModule_Create(&keywdargmodule);
}

1.9. Créer des valeurs arbitraires

Cette fonction est le complément de PyArg_ParseTuple(). Elle est déclarée comme suit :

PyObject *Py_BuildValue(const char *format, ...);

Il reconnaît un ensemble d'unités de format similaires à celles reconnues par PyArg_ParseTuple(), mais les arguments (qui sont les données en entrée de fonction, et non de la sortie) ne doivent pas être des pointeurs, mais juste des valeurs. Il renvoie un nouvel objet Python, adapté pour être renvoyé par une fonction C appelée depuis Python.

One difference with PyArg_ParseTuple(): while the latter requires its first argument to be a tuple (since Python argument lists are always represented as tuples internally), Py_BuildValue() does not always build a tuple. It builds a tuple only if its format string contains two or more format units. If the format string is empty, it returns None; if it contains exactly one format unit, it returns whatever object is described by that format unit. To force it to return a tuple of size 0 or one, parenthesize the format string.

Exemples (à gauche l'appel, à droite la valeur résultante, en Python) :

Py_BuildValue("")                        None
Py_BuildValue("i", 123)                  123
Py_BuildValue("iii", 123, 456, 789)      (123, 456, 789)
Py_BuildValue("s", "hello")              'hello'
Py_BuildValue("y", "hello")              b'hello'
Py_BuildValue("ss", "hello", "world")    ('hello', 'world')
Py_BuildValue("s#", "hello", 4)          'hell'
Py_BuildValue("y#", "hello", 4)          b'hell'
Py_BuildValue("()")                      ()
Py_BuildValue("(i)", 123)                (123,)
Py_BuildValue("(ii)", 123, 456)          (123, 456)
Py_BuildValue("(i,i)", 123, 456)         (123, 456)
Py_BuildValue("[i,i]", 123, 456)         [123, 456]
Py_BuildValue("{s:i,s:i}",
              "abc", 123, "def", 456)    {'abc': 123, 'def': 456}
Py_BuildValue("((ii)(ii)) (ii)",
              1, 2, 3, 4, 5, 6)          (((1, 2), (3, 4)), (5, 6))

1.10. Compteurs de références

Dans les langages comme le C ou le C++, le développeur est responsable de l'allocation dynamique et de la dés-allocation de la mémoire sur le tas. En C, cela se fait à l'aide des fonctions malloc() et free(). En C++, les opérateurs new et delete sont utilisés avec essentiellement la même signification et nous limiterons la discussion suivante au cas du C.

Every block of memory allocated with malloc() should eventually be returned to the pool of available memory by exactly one call to free(). It is important to call free() at the right time. If a block's address is forgotten but free() is not called for it, the memory it occupies cannot be reused until the program terminates. This is called a memory leak. On the other hand, if a program calls free() for a block and then continues to use the block, it creates a conflict with re-use of the block through another malloc() call. This is called using freed memory. It has the same bad consequences as referencing uninitialized data --- core dumps, wrong results, mysterious crashes.

Common causes of memory leaks are unusual paths through the code. For instance, a function may allocate a block of memory, do some calculation, and then free the block again. Now a change in the requirements for the function may add a test to the calculation that detects an error condition and can return prematurely from the function. It's easy to forget to free the allocated memory block when taking this premature exit, especially when it is added later to the code. Such leaks, once introduced, often go undetected for a long time: the error exit is taken only in a small fraction of all calls, and most modern machines have plenty of virtual memory, so the leak only becomes apparent in a long-running process that uses the leaking function frequently. Therefore, it's important to prevent leaks from happening by having a coding convention or strategy that minimizes this kind of errors.

Comme Python fait un usage intensif de malloc() et de free(), il a besoin d'une stratégie pour éviter les fuites de mémoire ainsi que l'utilisation de la mémoire libérée. La méthode choisie est appelée reference counting. Le principe est simple : chaque objet contient un compteur, qui est incrémenté lorsqu'une référence à l'objet est stockée quelque part, et qui est décrémenté lorsqu'une référence à celui-ci est supprimée. Lorsque le compteur atteint zéro, la dernière référence à l'objet a été supprimée et l'objet est libéré.

Une stratégie alternative est appelée automatic garbage collection (ramasse-miettes). Parfois, le comptage des références est également appelé stratégie de ramasse-miettes, d'où l'utilisation du terme "automatique" pour distinguer les deux. Le grand avantage du ramasse-miettes est que l'utilisateur n'a pas besoin d'appeler free() explicitement. (Un autre avantage important est l'amélioration de la vitesse ou de l'utilisation de la mémoire, ce n'est cependant pas un fait avéré). L'inconvénient est que pour C, il n'y a pas de ramasse-miettes portable proprement-dit, alors que le comptage des références peut être implémenté de façon portable (tant que les fonctions malloc() et free() soient disponibles, ce que la norme C garantit). Peut-être qu'un jour un ramasse-miettes suffisamment portable sera disponible pour C. D'ici là, nous devrons utiliser les compteurs des références.

Bien que Python utilise l'implémentation traditionnelle de comptage de référence, il contient également un détecteur de cycles qui fonctionne pour détecter les cycles de référence. Cela permet aux applications d'empêcher la création de références circulaires directes ou indirectes ; ceci sont les faiblesses du ramasse-miettes mis en œuvre en utilisant uniquement le comptage de référence. Les cycles de référence sont constitués d'objets qui contiennent des références (éventuellement indirectes) à eux-mêmes, de sorte que chaque objet du cycle a un comptage de référence qui n'est pas nul. Les implémentations typiques de comptage de référence ne sont pas capables de récupérer la mémoire appartenant à des objets dans un cycle de référence, ou référencés à partir des objets dans le cycle, même s'il n'y a pas d'autres références au cycle lui-même.

The cycle detector is able to detect garbage cycles and can reclaim them. The gc module exposes a way to run the detector (the collect() function), as well as configuration interfaces and the ability to disable the detector at runtime. The cycle detector is considered an optional component; though it is included by default, it can be disabled at build time using the --without-cycle-gc option to the configure script on Unix platforms (including Mac OS X). If the cycle detector is disabled in this way, the gc module will not be available.

1.10.1. Comptage de références en Python

Il existe deux macros, Py_INCREF(x) et Py_DECREF(x), qui gèrent l'incrémentation et la décrémentation du comptage de référence. Py_DECREF() libère également l'objet lorsque le comptage atteint zéro. Pour plus de flexibilité, il n'appelle pas free() directement — plutôt, il fait un appel à travers un pointeur de fonction dans l'objet type objet de l'objet. À cette fin (et pour d'autres), chaque objet contient également un pointeur vers son objet type.

La grande question demeure maintenant : quand utiliser Py_INCREF(x) et Py_DECREF(x) ? Commençons par définir quelques termes. Personne ne possède un objet, mais vous pouvez en avoir une référence. Le comptage de références d'un objet est maintenant défini comme étant le nombre de références à cet objet. Le propriétaire d'une référence est responsable d'appeler Py_DECREF() lorsque la référence n'est plus nécessaire. La propriété d'une référence peut être transférée. Il y a trois façons de disposer d'une référence : la transmettre, la stocker, ou appeler Py_DECREF(). Oublier de se débarrasser d'une référence crée une fuite de mémoire.

It is also possible to borrow 2 a reference to an object. The borrower of a reference should not call Py_DECREF(). The borrower must not hold on to the object longer than the owner from which it was borrowed. Using a borrowed reference after the owner has disposed of it risks using freed memory and should be avoided completely 3.

L'avantage d'emprunter, plutôt qu'être propriétaire d'une référence est que vous n'avez pas à vous soucier de disposer de la référence sur tous les chemins possibles dans le code — en d'autres termes, avec une référence empruntée, vous ne courez pas le risque de fuites lors d'une sortie prématurée. L'inconvénient de l'emprunt par rapport à la possession est qu'il existe certaines situations subtiles où, dans un code apparemment correct, une référence empruntée peut être utilisée après que le propriétaire auquel elle a été empruntée l'a en fait éliminée.

A borrowed reference can be changed into an owned reference by calling Py_INCREF(). This does not affect the status of the owner from which the reference was borrowed --- it creates a new owned reference, and gives full owner responsibilities (the new owner must dispose of the reference properly, as well as the previous owner).

1.10.2. Règles concernant la propriété de références

Chaque fois qu'une référence d'objet est passée à l'intérieur ou à l'extérieur d'une fonction, elle fait partie de la spécification de l'interface de la fonction, peu importe que la propriété soit transférée avec la référence ou non.

Most functions that return a reference to an object pass on ownership with the reference. In particular, all functions whose function it is to create a new object, such as PyLong_FromLong() and Py_BuildValue(), pass ownership to the receiver. Even if the object is not actually new, you still receive ownership of a new reference to that object. For instance, PyLong_FromLong() maintains a cache of popular values and can return a reference to a cached item.

Many functions that extract objects from other objects also transfer ownership with the reference, for instance PyObject_GetAttrString(). The picture is less clear, here, however, since a few common routines are exceptions: PyTuple_GetItem(), PyList_GetItem(), PyDict_GetItem(), and PyDict_GetItemString() all return references that you borrow from the tuple, list or dictionary.

The function PyImport_AddModule() also returns a borrowed reference, even though it may actually create the object it returns: this is possible because an owned reference to the object is stored in sys.modules.

When you pass an object reference into another function, in general, the function borrows the reference from you --- if it needs to store it, it will use Py_INCREF() to become an independent owner. There are exactly two important exceptions to this rule: PyTuple_SetItem() and PyList_SetItem(). These functions take over ownership of the item passed to them --- even if they fail! (Note that PyDict_SetItem() and friends don't take over ownership --- they are "normal.")

When a C function is called from Python, it borrows references to its arguments from the caller. The caller owns a reference to the object, so the borrowed reference's lifetime is guaranteed until the function returns. Only when such a borrowed reference must be stored or passed on, it must be turned into an owned reference by calling Py_INCREF().

The object reference returned from a C function that is called from Python must be an owned reference --- ownership is transferred from the function to its caller.

1.10.3. Terrain dangereux

Il existe quelques situations où l'utilisation apparemment inoffensive d'une référence empruntée peut entraîner des problèmes. Tous ces problèmes sont en lien avec des invocations implicites de l’interpréteur, et peuvent amener le propriétaire d'une référence à s'en défaire.

Le premier cas, et le plus important à connaître, est celui de l'application de Py_DECREF() à un objet non relié, tout en empruntant une référence à un élément de liste. Par exemple :

void
bug(PyObject *list)
{
    PyObject *item = PyList_GetItem(list, 0);

    PyList_SetItem(list, 1, PyLong_FromLong(0L));
    PyObject_Print(item, stdout, 0); /* BUG! */
}

Cette fonction emprunte d'abord une référence à list[0], puis remplace list[1] par la valeur 0, et enfin affiche la référence empruntée. Ça a l'air inoffensif, n'est-ce pas ? Mais ce n'est pas le cas !

Suivons le flux de contrôle dans PyList_SetItem(). La liste possède des références à tous ses éléments, donc quand l'élément 1 est remplacé, elle doit se débarrasser de l'élément 1 original. Supposons maintenant que l'élément 1 original était une instance d'une classe définie par l'utilisateur, et supposons en outre que la classe définisse une méthode __del__(). Si l'instance de cette classe a un nombre des références de 1, sa destruction appellera sa méthode __del__().

Comme elle est écrite en Python, la méthode __del__() peut exécuter du code Python arbitraire. Pourrait-elle faire quelque chose pour invalider la référence à item dans bug() ? Bien sûr ! En supposant que la liste passée dans bug() est accessible à la méthode __del__(), elle pourrait exécuter une instruction à l'effet de del list[0], et en supposant que ce soit la dernière référence à cet objet, elle libérerait la mémoire qui lui est associée, invalidant ainsi item.

The solution, once you know the source of the problem, is easy: temporarily increment the reference count. The correct version of the function reads:

void
no_bug(PyObject *list)
{
    PyObject *item = PyList_GetItem(list, 0);

    Py_INCREF(item);
    PyList_SetItem(list, 1, PyLong_FromLong(0L));
    PyObject_Print(item, stdout, 0);
    Py_DECREF(item);
}

This is a true story. An older version of Python contained variants of this bug and someone spent a considerable amount of time in a C debugger to figure out why his __del__() methods would fail...

Le deuxième cas de problèmes liés à une référence empruntée est une variante impliquant des fils de discussion. Normalement, plusieurs threads dans l'interpréteur Python ne peuvent pas se gêner mutuellement, car il existe un verrou global protégeant tout l'espace objet de Python. Cependant, il est possible de libérer temporairement ce verrou en utilisant la macro Py_BEGIN_ALLOW_THREADS, et de le ré-acquérir en utilisant Py_END_ALLOW_THREADS. Ceci est un procédé courant pour bloquer les appels d'entrées/sorties, afin de permettre aux autres threads d'utiliser le processeur en attendant que les E/S soient terminées. Évidemment, la fonction suivante a le même problème que la précédente :

void
bug(PyObject *list)
{
    PyObject *item = PyList_GetItem(list, 0);
    Py_BEGIN_ALLOW_THREADS
    ...some blocking I/O call...
    Py_END_ALLOW_THREADS
    PyObject_Print(item, stdout, 0); /* BUG! */
}

1.10.4. Pointeurs NULL

En général, les fonctions qui prennent des références d'objets comme arguments ne sont pas conçues pour recevoir des pointeurs NULL, et si vous en donnez comme arguments, elles causeront une erreur de segmentation (ou provoqueront des core dump ultérieurs). Les fonctions qui renvoient des références d'objets renvoient généralement NULL uniquement pour indiquer qu'une exception s'est produite. La raison pour laquelle les arguments NULL ne sont pas testés est que les fonctions passent souvent les objets qu'elles reçoivent à d'autres fonctions, si chaque fonction devait tester pour NULL, il y aurait beaucoup de tests redondants et le code s'exécuterait plus lentement.

Il est préférable de tester la présence de NULL uniquement au début : lorsqu'un pointeur qui peut être NULL est reçu, par exemple, de malloc() ou d'une fonction qui peut lever une exception.

Les macros Py_INCREF() et Py_DECREF() ne vérifient pas les pointeurs NULL. Cependant, leurs variantes Py_XINCREF() et Py_XDECREF() le font.

The macros for checking for a particular object type (Pytype_Check()) don't check for NULL pointers --- again, there is much code that calls several of these in a row to test an object against various different expected types, and this would generate redundant tests. There are no variants with NULL checking.

Le mécanisme d'appel de fonctions C garantit que la liste d'arguments passée aux fonctions C (args dans les exemples) n'est jamais NULL. En fait, il garantit qu'il s'agit toujours d'un n-uplet 4.

C'est une grave erreur de laisser un pointeur NULL "échapper" à l'utilisateur Python.

1.11. Écrire des extensions en C++

C'est possible d'écrire des modules d'extension en C++, mais sous certaines conditions. Si le programme principal (l'interpréteur Python) est compilé et lié par le compilateur C, les objets globaux ou statiques avec les constructeurs ne peuvent pas être utilisés. Ceci n'est pas un problème si le programme principal est relié par le compilateur C++. Les fonctions qui seront appelées par l'interpréteur Python (en particulier, les fonctions d'initialisation des modules) doivent être déclarées en utilisant extern "C". Il n'est pas nécessaire d'inclure les fichiers d'en-tête Python dans le extern "C" {…}, car ils utilisent déjà ce format si le symbole __cplusplus est défini (tous les compilateurs C++ récents définissent ce symbole).

1.12. Fournir une API en langage C pour un module d'extension

De nombreux modules d'extension fournissent simplement de nouvelles fonctions et de nouveaux types à utiliser à partir de Python, mais parfois le code d'un module d'extension peut être utile pour d'autres modules d'extension. Par exemple, un module d'extension peut mettre en œuvre un type "collection" qui fonctionne comme des listes sans ordre. Tout comme le type de liste Python standard possède une API C qui permet aux modules d'extension de créer et de manipuler des listes, ce nouveau type de collection devrait posséder un ensemble de fonctions C pour une manipulation directe à partir d'autres modules d'extension.

À première vue, cela semble facile : il suffit d'écrire les fonctions (sans les déclarer "statiques", bien sûr), de fournir un fichier d'en-tête approprié et de documenter l'API C. Et en fait, cela fonctionnerait si tous les modules d'extension étaient toujours liés statiquement avec l'interpréteur Python. Cependant, lorsque les modules sont utilisés comme des bibliothèques partagées, les symboles définis dans un module peuvent ne pas être visibles par un autre module. Les détails de la visibilité dépendent du système d'exploitation ; certains systèmes utilisent un espace de noms global pour l'interpréteur Python et tous les modules d'extension (Windows, par exemple), tandis que d'autres exigent une liste explicite des symboles importés au moment de la liaison des modules (AIX en est un exemple), ou offrent un choix de stratégies différentes (la plupart des Unix). Et même si les symboles sont globalement visibles, le module dont on souhaite appeler les fonctions n'est peut-être pas encore chargé !

La portabilité exige donc de ne faire aucune supposition sur la visibilité des symboles. Cela signifie que tous les symboles des modules d'extension doivent être déclarés static, à l'exception de la fonction d'initialisation du module, afin d'éviter les conflits de noms avec les autres modules d'extension (comme discuté dans la section La fonction d'initialisation et le tableau des méthodes du module). Et cela signifie que les symboles qui devraient être accessibles à partir d'autres modules d'extension doivent être exportés d'une manière différente.

Python provides a special mechanism to pass C-level information (pointers) from one extension module to another one: Capsules. A Capsule is a Python data type which stores a pointer (void *). Capsules can only be created and accessed via their C API, but they can be passed around like any other Python object. In particular, they can be assigned to a name in an extension module's namespace. Other extension modules can then import this module, retrieve the value of this name, and then retrieve the pointer from the Capsule.

Il existe de nombreuses façons d'utiliser les Capsules pour exporter l'API C d'un module d'extension. Chaque fonction peut obtenir sa propre Capsule, ou tous les pointeurs de l'API C peuvent être stockés dans un tableau dont l'adresse est inscrite dans une Capsule. Et les différentes tâches de stockage et de récupération des pointeurs peuvent être réparties de différentes manières entre le module fournissant le code et les modules clients.

Whichever method you choose, it's important to name your Capsules properly. The function PyCapsule_New() takes a name parameter (const char *); you're permitted to pass in a NULL name, but we strongly encourage you to specify a name. Properly named Capsules provide a degree of runtime type-safety; there is no feasible way to tell one unnamed Capsule from another.

In particular, Capsules used to expose C APIs should be given a name following this convention:

modulename.attributename

The convenience function PyCapsule_Import() makes it easy to load a C API provided via a Capsule, but only if the Capsule's name matches this convention. This behavior gives C API users a high degree of certainty that the Capsule they load contains the correct C API.

L'exemple suivant montre une approche qui fait peser la plus grande partie de la charge sur le rédacteur du module d'exportation, ce qui est approprié pour les modules de bibliothèque couramment utilisés. Il stocke tous les pointeurs de l'API C (un seul dans l'exemple !) dans un tableau de pointeurs void qui devient la valeur d'une Capsule. Le fichier d'en-tête correspondant au module fournit une macro qui se charge d'importer le module et de récupérer ses pointeurs d'API C. Les modules clients n'ont qu'à appeler cette macro avant d'accéder à l'API C.

Le module d'exportation est une modification du module spam de la section Un exemple simple. La fonction spam.system() n'appelle pas directement la fonction de la bibliothèque C system(), mais une fonction PySpam_System(), qui ferait bien sûr quelque chose de plus compliqué en réalité (comme ajouter du spam à chaque commande). Cette fonction PySpam_System() est également exportée vers d'autres modules d'extension.

The function PySpam_System() is a plain C function, declared static like everything else:

static int
PySpam_System(const char *command)
{
    return system(command);
}

La fonction spam_system() est modifiée de manière simple :

static PyObject *
spam_system(PyObject *self, PyObject *args)
{
    const char *command;
    int sts;

    if (!PyArg_ParseTuple(args, "s", &command))
        return NULL;
    sts = PySpam_System(command);
    return PyLong_FromLong(sts);
}

Au début du module, immédiatement après la ligne :

#include <Python.h>

on doit ajouter deux lignes supplémentaires :

#define SPAM_MODULE
#include "spammodule.h"

L'indicateur #define est utilisé pour indiquer au fichier d'en-tête qu'il est inclus dans le module d'exportation, et non dans un module client. Enfin, la fonction d'initialisation du module doit prendre en charge l'initialisation du tableau de pointeurs de l'API C :

PyMODINIT_FUNC
PyInit_spam(void)
{
    PyObject *m;
    static void *PySpam_API[PySpam_API_pointers];
    PyObject *c_api_object;

    m = PyModule_Create(&spammodule);
    if (m == NULL)
        return NULL;

    /* Initialize the C API pointer array */
    PySpam_API[PySpam_System_NUM] = (void *)PySpam_System;

    /* Create a Capsule containing the API pointer array's address */
    c_api_object = PyCapsule_New((void *)PySpam_API, "spam._C_API", NULL);

    if (PyModule_AddObject(m, "_C_API", c_api_object) < 0) {
        Py_XDECREF(c_api_object);
        Py_DECREF(m);
        return NULL;
    }

    return m;
}

Notez que PySpam_API est déclaré static ; sinon le tableau de pointeurs disparaîtrait lorsque PyInit_spam`() se finit !

L'essentiel du travail se trouve dans le fichier d'en-tête spammodule.h, qui ressemble à ceci :

#ifndef Py_SPAMMODULE_H
#define Py_SPAMMODULE_H
#ifdef __cplusplus
extern "C" {
#endif

/* Header file for spammodule */

/* C API functions */
#define PySpam_System_NUM 0
#define PySpam_System_RETURN int
#define PySpam_System_PROTO (const char *command)

/* Total number of C API pointers */
#define PySpam_API_pointers 1


#ifdef SPAM_MODULE
/* This section is used when compiling spammodule.c */

static PySpam_System_RETURN PySpam_System PySpam_System_PROTO;

#else
/* This section is used in modules that use spammodule's API */

static void **PySpam_API;

#define PySpam_System \
 (*(PySpam_System_RETURN (*)PySpam_System_PROTO) PySpam_API[PySpam_System_NUM])

/* Return -1 on error, 0 on success.
 * PyCapsule_Import will set an exception if there's an error.
 */
static int
import_spam(void)
{
    PySpam_API = (void **)PyCapsule_Import("spam._C_API", 0);
    return (PySpam_API != NULL) ? 0 : -1;
}

#endif

#ifdef __cplusplus
}
#endif

#endif /* !defined(Py_SPAMMODULE_H) */

Tout ce qu'un module client doit faire pour avoir accès à la fonction PySpam_System() est d'appeler la fonction (ou plutôt la macro) import_spam() dans sa fonction d'initialisation :

PyMODINIT_FUNC
PyInit_client(void)
{
    PyObject *m;

    m = PyModule_Create(&clientmodule);
    if (m == NULL)
        return NULL;
    if (import_spam() < 0)
        return NULL;
    /* additional initialization can happen here */
    return m;
}

Le principal inconvénient de cette approche est que le fichier spammodule.h est assez compliqué. Cependant, la structure de base est la même pour chaque fonction exportée, ce qui fait qu'elle ne doit être apprise qu'une seule fois.

Enfin, il convient de mentionner que Capsules offrent des fonctionnalités supplémentaires, qui sont particulièrement utiles pour l'allocation de la mémoire et la dés-allocation du pointeur stocké dans un objet Capsule. Les détails sont décrits dans le manuel de référence de l'API Python/C dans la section Capsules et dans l'implémentation des Capsules (fichiers Include/pycapsule.h et Objects/pycapsule.c dans la distribution du code source Python).

Notes

1

Une interface pour cette fonction existe déjà dans le module standard os, elle a été choisie comme un exemple simple et direct.

2

L'expression « emprunter une référence » n'est pas tout à fait correcte, car le propriétaire a toujours une copie de la référence.

3

Vérifier que le comptage de référence est d'au moins 1 ne fonctionne pas, le compte de référence lui-même pourrait être en mémoire libérée et peut donc être réutilisé pour un autre objet !

4

Ces garanties ne sont pas valables lorsqu'on emploie les conventions de nommage anciennes, qu'on retrouve encore assez souvent dans beaucoup de code existant.