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()" returns true (nonzero) if all arguments have the
right type and its components have been stored in the variables whose
addresses are passed.  It returns false (zero) if an invalid argument
list was passed.  In the latter case it also raises an appropriate
exception so the calling function can return "NULL" immediately (as we
saw in the example).


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.

You can test non-destructively whether an exception has been set with
"PyErr_Occurred()".  This returns the current exception object, or
"NULL" if no exception has occurred.  You normally don't need to call
"PyErr_Occurred()" to see whether an error occurred in a function
call, since you should be able to tell from the return value.

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;

and initialize it in your module's initialization function
("PyInit_spam()") with an exception object:

   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;
   }

Note that the Python name for the exception object is "spam.error".
The "PyErr_NewException()" function may create a class with the base
class being "Exception" (unless another class is passed in instead of
"NULL"), described in 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;

It returns "NULL" (the error indicator for functions returning object
pointers) if an error is detected in the argument list, relying on the
exception set by "PyArg_ParseTuple()".  Otherwise the string value of
the argument has been copied to the local variable "command".  This is
a pointer assignment and you are not supposed to modify the string to
which it points (so in Standard C, the variable "command" should
properly be declared as "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" is the C name for the special Python object "None".  It is a
genuine Python object rather than a "NULL" pointer, which means
"error" in most contexts, as we have seen.


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".

When the Python program imports module "spam" for the first time,
"PyInit_spam()" is called. (See below for comments about embedding
Python.) It calls "PyModule_Create()", which returns a module object,
and inserts built-in function objects into the newly created module
based upon the table (an array of "PyMethodDef" structures) found in
the module definition. "PyModule_Create()" returns a pointer to the
module object that it creates.  It may abort with a fatal error for
certain errors, or return "NULL" if the module could not be
initialized satisfactorily. The init function must return the module
object to its caller, so that it then gets inserted into
"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 */
       PyImport_AppendInittab("spam", PyInit_spam);

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

       /* Initialize the Python interpreter.  Required. */
       Py_Initialize();

       /* Optionally import the module; alternatively,
          import can be deferred until the embedded script
          imports it. */
       PyImport_ImportModule("spam");

       ...

       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.

The macros "Py_XINCREF()" and "Py_XDECREF()" increment/decrement the
reference count of an object and are safe in the presence of "NULL"
pointers (but note that *temp* will not be  "NULL" in this context).
More info on them in 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.

Before you do this, however, it is important to check that the return
value isn't "NULL".  If it is, the Python function terminated by
raising an exception. If the C code that called
"PyObject_CallObject()" is called from Python, it should now return an
error indication to its Python caller, so the interpreter can print a
stack trace, or the calling Python code can handle the exception. If
this is not possible or desirable, the exception should be cleared by
calling "PyErr_Clear()".  For example:

   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[], ...);

The *arg* and *format* parameters are identical to those of the
"PyArg_ParseTuple()" function.  The *kwdict* parameter is the
dictionary of keywords received as the third parameter from the Python
runtime.  The *kwlist* parameter is a "NULL"-terminated list of
strings which identify the parameters; the names are matched with the
type information from *format* from left to right.  On success,
"PyArg_ParseTupleAndKeywords()" returns true, otherwise it returns
false and raises an appropriate exception.

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)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"
------------------------

In general, functions that take object references as arguments do not
expect you to pass them "NULL" pointers, and will dump core (or cause
later core dumps) if you do so.  Functions that return object
references generally return "NULL" only to indicate that an exception
occurred.  The reason for not testing for "NULL" arguments is that
functions often pass the objects they receive on to other function ---
if each function were to test for "NULL", there would be a lot of
redundant tests and the code would run more slowly.

It is better to test for "NULL" only at the "source:" when a pointer
that may be "NULL" is received, for example, from "malloc()" or from a
function that may raise an exception.

The macros "Py_INCREF()" and "Py_DECREF()" do not check for "NULL"
pointers --- however, their variants "Py_XINCREF()" and "Py_XDECREF()"
do.

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.

The C function calling mechanism guarantees that the argument list
passed to C functions ("args" in the examples) is never "NULL" --- in
fact it guarantees that it is always a tuple [4].

It is a severe error to ever let a "NULL" pointer "escape" to the
Python user.


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.
