Guide Argument Clinic
*********************

auteur:
   Larry Hastings


Résumé
^^^^^^

Argument Clinic est un préprocesseur pour les fichiers C de CPython.
Il permet d'automatiser les tâches répétitives lors de la rédaction du
code d'analyse d'arguments pour les modules natifs.  Ce document vous
montre comment convertir votre première fonction C de façon à ce
qu'elle fonctionne avec Argument Clinic, avant d'introduire des usages
plus avancés d'Argument Clinic.

Argument Clinic est pour le moment considéré comme un outil interne à
CPython.  Il n'est pas conçu pour gérer des fichiers à l'extérieur de
CPython, et sa compatibilité ascendante n'est pas garantie pour les
versions futures. En d'autres termes, si vous êtes mainteneur d'une
extension C pour CPython, vous pouvez bien sûr expérimenter avec
Argument Clinic sur votre propre code. Mais la version d'Argument
Clinic livrée avec la prochaine version de CPython *pourrait* être
totalement incompatible et casser tout votre code.


Les objectifs d'Argument Clinic
===============================

Le premier objectif d'Argument Clinic est de prendre en charge toute
l'analyse d'arguments à l'intérieur de CPython. Cela signifie que si
vous convertissez une fonction pour utiliser Argument Clinic, cette
fonction n'a plus du tout besoin d'analyser ses propres arguments. Le
code généré par Argument Clinic doit être une « boîte noire » avec en
entrée l'appel de CPython, et en sortie l'appel à votre code. Entre
les deux, "PyObject *args" (et éventuellement "PyObject *kwargs") sont
convertis magiquement dans les variables et types C dont vous avez
besoin.

Pour que le premier objectif d'Argument Clinic soit atteint, il faut
qu'il soit facile à utiliser. Actuellement, travailler avec la
bibliothèque d'analyse d'arguments de CPython est une corvée. Il faut
maintenir une quantité surprenante d'informations redondantes. En
utilisant Argument Clinic, il n'est plus nécessaire de se répéter.

Certainement, personne ne voudrait utiliser Argument Clinic s'il ne
réglait pas son problème sans en créer de nouveaux. Il est donc de la
première importance qu'Argument Clinic génère du code correct. Il est
aussi souhaitable que le code soit aussi plus rapide. Au minimum, il
ne doit pas introduire de régression significative sur la vitesse
d'exécution. (Au bout du compte, Argument Clinic *devrait* permettre
une accélération importante, on pourrait ré-écrire son générateur de
code pour produire du code d'analyse d'arguments adapté au mieux,
plutôt que d'utiliser la bibliothèque d'analyse d'arguments générique.
On aurait ainsi l'analyse d'arguments la plus rapide possible !)

De plus, Argument Clinic doit être suffisamment flexible pour
s'accommoder d'approches différentes de l'analyse d'arguments. Il y a
des fonctions dans Python dont le traitement des arguments est très
étrange ; le but d'Argument Clinic est de les gérer toutes.

Finalement, la motivation première d'Argument Clinic était de fournir
des « signatures » pour l'introspection des composants natifs de
CPython. Précédemment, les fonctions d'introspection levaient une
exception si vous passiez un composant natif. Grâce à Argument Clinic,
ce comportement appartient au passé !

En travaillant avec Argument Clinic, il faut garder à l'esprit que
plus vous lui donnez de détails, meilleur sera son boulot. Argument
Clinic est bien sûr assez simple pour le moment. Mais à mesure qu'il
évoluera et deviendra plus sophistiqué, il sera capable de faire
beaucoup de choses intéressantes et intelligentes à partir de
l'information à sa disposition.


Concepts de base et utilisation
===============================

Argument Clinic est livré avec CPython ; vous le trouverez dans
"Tools/clinic/clinic.py". Si vous exécutez ce script, en spécifiant un
fichier C comme argument :

   $ python3 Tools/clinic/clinic.py foo.c

Argument Clinic va parcourir le fichier en cherchant cette ligne :

   /*[clinic input]

Lorsqu'il en trouve une, il lit tout ce qui suit, jusqu'à cette ligne
:

   [clinic start generated code]*/

Tout ce qui se trouve entre ces deux lignes est une entrée pour
Argument Clinic. Toutes ces lignes, en incluant les commentaires de
début et de fin, sont appelées collectivement un « bloc » d'Argument
Clinic.

Lorsque *Argument Clinic* analyse l'un de ces blocs, il produit une
sortie. Cette sortie est réécrite dans le fichier C immédiatement
après le bloc, suivie par un commentaire contenant une somme de
contrôle. Le bloc Argument Clinic ressemble maintenant à cela :

   /*[clinic input]
   ... clinic input goes here ...
   [clinic start generated code]*/
   ... clinic output goes here ...
   /*[clinic end generated code: checksum=...]*/

Si vous exécutez de nouveau Argument Clinic sur ce même fichier,
Argument Clinic supprime la vieille sortie, et écrit la nouvelle
sortie avec une ligne de somme de contrôle mise à jour. Cependant, si
l'entrée n'a pas changé, la sortie ne change pas non plus.

Vous ne devez jamais modifier la sortie d'un bloc Argument Clinic.
Changez plutôt l'entrée jusqu'à obtenir la sortie souhaitée (c'est
précisément le but de la somme de contrôle, détecter si la sortie a
été changée. En effet, ces modifications seront perdues après que
Argument Clinic a écrit une nouvelle sortie).

Par souci de clarté, voilà la terminologie que nous emploierons :

* La première ligne du commentaire ("/*[clinic input]") est la *ligne
  de début*.

* La dernière ligne du commentaire initial ("[clinic start generated
  code]*/") est la *ligne de fin*.

* La dernière ligne ("/*[clinic end generated code: checksum=...]*/")
  est la *ligne de contrôle*.

* On appelle *entrée* ce qui se trouve entre la ligne de début et la
  ligne de fin.

* Et on appelle *sortie* ce qui se trouve entre la ligne de fin et la
  ligne de contrôle.

* L'ensemble du texte, depuis la ligne de début jusqu'à la ligne de
  contrôle incluse s'appelle le *bloc*. (Un bloc qui n'a pas encore
  été traité avec succès par Argument Clinic n'a pas encore de sortie
  ni de ligne de contrôle mais est quand même considéré comme un bloc)


Convertissez votre première fonction
====================================

La meilleure manière de comprendre le fonctionnement d'Argument Clinic
est de convertir une fonction. Voici donc les étapes minimales que
vous devez suivre pour convertir une fonction de manière à ce qu'elle
fonctionne avec Argument Clinic. Remarquez que pour du code que vous
comptez inclure dans CPython, vous devrez certainement pousser plus
loin la conversion, en utilisant les concepts avancés que nous verrons
plus loin dans ce document (comme "return converters" et "self
converters"). Mais concentrons nous pour le moment sur les choses
simples.

En route !

* Assurez-vous que vous travaillez sur une copie récemment mise à jour
  du code de CPython.

* Trouvez une fonction native de Python qui fait appel à
  "PyArg_ParseTuple()" ou "PyArg_ParseTupleAndKeywords()", et n'a pas
  encore été convertie par Argument Clinic. Pour cet exemple,
  j'utilise "_pickle.Pickler.dump()".

* Si l'appel à "PyArg_Parse" utilise l'un des formats suivants :

     O&
     O!
     es
     es#
     et
     et#

  ou s'il y a de multiples appels à "PyArg_ParseTuple()", choisissez
  une fonction différente. Argument Clinic gère tous ces scénarios,
  mais ce sont des sujets trop avancés pour notre première fonction.

  Par ailleurs, si la fonction a des appels multiples à
  "PyArg_ParseTuple()" ou "PyArg_ParseTupleAndKeywords()" dans
  lesquels elle permet différents types pour les mêmes arguments, il
  n'est probablement pas possible de la convertir pour Argument
  Clinic. Argument Clinic ne gère pas les fonctions génériques ou les
  paramètres polymorphes.

* Ajoutez les lignes standard suivantes au-dessus de votre fonction
  pour créer notre bloc :

     /*[clinic input]
     [clinic start generated code]*/

* Coupez la *docstring* et collez-la entre les lignes commençant par
  "[clinic]", en enlevant tout le bazar qui en fait une chaîne de
  caractères correcte en C. Une fois que c'est fait, vous devez avoir
  seulement le texte, aligné à gauche, sans ligne plus longue que 80
  caractères (Argument Clinic préserve l'indentation à l'intérieur de
  la *docstring*).

  Si l'ancienne *docstring* commençait par une ligne qui ressemble à
  une signature de fonction, supprimez cette ligne. (Elle n'est plus
  nécessaire pour la *docstring*. Dans le futur, quand vous utiliserez
  "help()" pour une fonction native, la première ligne sera construite
  automatiquement à partir de la signature de la fonction.)

  Échantillon :

     /*[clinic input]
     Write a pickled representation of obj to the open file.
     [clinic start generated code]*/

* Si votre *docstring* ne contient pas de ligne « résumé », Argument
  Clinic va se plaindre. Assurons-nous donc qu'il y en a une. La ligne
  « résumé » doit être un paragraphe consistant en une seule ligne de
  80 colonnes au début de la *docstring*.

  Dans notre exemple, la *docstring* est seulement composée d'une
  ligne de résumé, donc le code ne change pas à cette étape.

* Au-dessus de la *docstring*, entrez le nom de la fonction, suivi
  d'une ligne vide. Ce doit être le nom de la fonction en Python et
  être le chemin complet jusqu'à la fonction. Il doit commencer par le
  nom du module, suivi de tous les sous-modules, puis, si la fonction
  est une méthode de classe, inclure aussi le nom de la classe.

  Échantillon :

     /*[clinic input]
     _pickle.Pickler.dump

     Write a pickled representation of obj to the open file.
     [clinic start generated code]*/

* Si c'est la première fois que ce module ou cette classe est utilisée
  avec Argument Clinic dans ce fichier C, vous devez déclarer votre
  module et/ou votre classe. Pour suivre de bonnes pratiques avec
  Argument Clinic, il vaut mieux faire ces déclarations quelque part
  en tête du fichier C, comme les fichiers inclus et les statiques
  (dans cet extrait, nous montrons les deux blocs à côté l'un de
  l'autre).

  Le nom de la classe et du module doivent être les mêmes que ceux vus
  par Python. Selon le cas, référez-vous à "PyModuleDef" ou
  "PyTypeObject"

  Quand vous déclarez une classe, vous devez aussi spécifier deux
  aspects de son type en C : la déclaration de type que vous
  utiliseriez pour un pointeur vers une instance de cette classe et un
  pointeur vers le "PyTypeObject" de cette classe.

  Échantillon :

     /*[clinic input]
     module _pickle
     class _pickle.Pickler "PicklerObject *" "&Pickler_Type"
     [clinic start generated code]*/

     /*[clinic input]
     _pickle.Pickler.dump

     Write a pickled representation of obj to the open file.
     [clinic start generated code]*/

* Déclarez chacun des paramètres de la fonction. Chaque paramètre doit
  être sur une ligne séparée. Tous les paramètres doivent être
  indentés par rapport au nom de la fonction et à la *docstring*.

  La forme générale de ces paramètres est la suivante :

     name_of_parameter: converter

  Si le paramètre a une valeur par défaut, ajoutez ceci après le
  convertisseur :

     name_of_parameter: converter = default_value

  Argument Clinic peut traiter les « valeurs par défaut » de manière
  assez sophistiquée ; voyez la section ci-dessous sur les valeurs par
  défaut pour plus de détails.

  Ajoutez une ligne vide sous les paramètres.

  Que fait le « convertisseur » ? Il établit à la fois le type de
  variable utilisé en C et la méthode pour convertir la valeur Python
  en valeur C lors de l'exécution.  Pour le moment, vous allez
  utiliser ce qui s'appelle un « convertisseur hérité », une syntaxe
  de convenance qui facilite le portage de vieux code dans Argument
  Clinic.

  Pour chaque paramètre, copiez la « spécification de format » de ce
  paramètre à partir de l'argument de "PyArg_Parse()" et spécifiez
  *ça* comme convertisseur, entre guillemets. (la « spécification de
  format » est le nom formel pour la partie du paramètre "format", de
  un à trois caractères, qui indique à la fonction d'analyse
  d'arguments quel est le type de la variable et comment la convertir.
  Pour plus d'information sur les spécifications de format, voyez
  Analyse des arguments et construction des valeurs.)

  Pour des spécifications de format de plusieurs caractères, comme
  "z#", utilisez l'ensemble des 2 ou 3 caractères de la chaîne.

  Échantillon :

      /*[clinic input]
      module _pickle
      class _pickle.Pickler "PicklerObject *" "&Pickler_Type"
      [clinic start generated code]*/

      /*[clinic input]
      _pickle.Pickler.dump

         obj: 'O'

     Write a pickled representation of obj to the open file.
     [clinic start generated code]*/

* Si votre fonction a le caractère "|" dans son format, parce que
  certains paramètres ont des valeurs par défaut, vous pouvez
  l'ignorer. Argument Clinic infère quels paramètres sont optionnels
  selon s'ils ont ou non une valeur par défaut.

  Si votre fonction a le caractère "$" dans son format, parce qu'elle
  n'accepte que des arguments nommés, spécifiez "*" sur une ligne à
  part, avant le premier argument nommé, avec la même indentation que
  les lignes de paramètres.

  ("_pickle.Pickler.dump" n'a ni l'un ni l'autre, donc notre exemple
  est inchangé.)

* Si la fonction C existante appelle "PyArg_ParseTuple()" (et pas
  "PyArg_ParseTupleAndKeywords()"), alors tous ses arguments sont
  uniquement positionnels.

  Pour marquer tous les paramètres comme uniquement positionnels dans
  Argument Clinic, ajoutez "/" sur une ligne à part après le dernier
  paramètre, avec la même indentation que les lignes de paramètres.

  Pour le moment, c'est tout ou rien ; soit tous les paramètres sont
  uniquement positionnels, ou aucun ne l'est. (Dans le futur, Argument
  Clinic supprimera peut-être cette restriction.)

  Échantillon :

     /*[clinic input]
     module _pickle
     class _pickle.Pickler "PicklerObject *" "&Pickler_Type"
     [clinic start generated code]*/

     /*[clinic input]
     _pickle.Pickler.dump

         obj: 'O'
         /

     Write a pickled representation of obj to the open file.
     [clinic start generated code]*/

* Il est utile d'ajouter une *docstring* pour chaque paramètre, mais
  c'est optionnel ; vous pouvez passer cette étape si vous préférez.

  Voici comment ajouter la *docstring* d'un paramètre. La première
  ligne doit être plus indentée que la définition du paramètre. La
  marge gauche de cette première ligne établit la marge gauche pour
  l'ensemble de la *docstring* de ce paramètre ; tout le texte que
  vous écrivez sera indenté de cette quantité. Vous pouvez écrire
  autant de texte que vous le souhaitez, sur plusieurs lignes.

  Échantillon :

     /*[clinic input]
     module _pickle
     class _pickle.Pickler "PicklerObject *" "&Pickler_Type"
     [clinic start generated code]*/

     /*[clinic input]
     _pickle.Pickler.dump

         obj: 'O'
             The object to be pickled.
         /

     Write a pickled representation of obj to the open file.
     [clinic start generated code]*/

* Enregistrez puis fermez le fichier, puis exécutez
  "Tools/clinic/clinic.py" dessus. Avec un peu de chance tout a
  fonctionné, votre bloc a maintenant une sortie, et un fichier ".c.h"
  a été généré ! Ré-ouvrez le fichier dans votre éditeur pour voir :

     /*[clinic input]
     _pickle.Pickler.dump

         obj: 'O'
             The object to be pickled.
         /

     Write a pickled representation of obj to the open file.
     [clinic start generated code]*/

     static PyObject *
     _pickle_Pickler_dump(PicklerObject *self, PyObject *obj)
     /*[clinic end generated code: output=87ecad1261e02ac7 input=552eb1c0f52260d9]*/

  Bien sûr, si Argument Clinic n'a pas produit de sortie, c'est qu'il
  a rencontré une erreur dans votre entrée. Corrigez vos erreurs et
  réessayez jusqu'à ce qu'Argument Clinic traite votre fichier sans
  problème.

  Pour plus de visibilité, la plupart du code a été écrit dans un
  fichier ".c.h". Vous devez l'inclure dans votre fichier ".c"
  original, typiquement juste après le bloc du module *clinic* :

     #include "clinic/_pickle.c.h"

* Vérifiez bien que le code d'analyse d'arguments généré par Argument
  Clinic ressemble bien au code existant.

  Assurez vous premièrement que les deux codes utilisent la même
  fonction pour analyser les arguments. Le code existant doit appeler
  soit "PyArg_ParseTuple()" soit "PyArg_ParseTupleAndKeywords()" ;
  assurez vous que le code généré par Argument Clinic appelle
  *exactement* la même fonction.

  Deuxièmement, la chaîne de caractère du format passée dans
  "PyArg_ParseTuple()" ou "PyArg_ParseTupleAndKeywords()" doit être
  *exactement* la même que celle écrite à la main, jusqu'aux deux
  points ou au point virgule.

  (Argument Clinic génère toujours ses chaînes de format avec ":"
  suivi du nom de la fonction. Si la chaîne de format du code existant
  termine par `` ;``, pour fournir une aide sur l'utilisation, ce
  changement n'a aucun effet, ne vous en souciez pas.)

  Troisièmement, pour des paramètres dont la spécification de format
  nécessite deux arguments (comme une variable de longueur, ou une
  chaîne d'encodage, ou un pointeur vers une fonction de conversion),
  assurez vous que ce deuxième argument est *exactement* le même entre
  les deux invocations.

  Quatrièmement, à l'intérieur de la section sortie du bloc, vous
  trouverez une macro pré-processeur qui définit les structures
  statiques "PyMethodDef" appropriées pour ce module natif :

     #define __PICKLE_PICKLER_DUMP_METHODDEF    \
     {"dump", (PyCFunction)__pickle_Pickler_dump, METH_O, __pickle_Pickler_dump__doc__},

  Cette structure statique doit être *exactement* la même que la
  structure statique "PyMethodDef" existante pour ce module natif.

  Si l'un de ces éléments diffère *de quelque façon que se soit*,
  ajustez la spécification de fonction d'Argument Clinic et exécutez
  de nouveau "Tools/clinic/clinic.py" jusqu'à ce qu'elles soient
  identiques.

* Notez que la dernière ligne de cette sortie est la déclaration de
  votre fonction "impl". C'est là que se trouve l'implémentation de la
  fonction native. Supprimez le prototype de la fonction que vous
  modifiez, mais laissez l'accolade ouverte. Maintenant, supprimez
  tout le code d'analyse d'arguments et les déclarations de toutes les
  variables auxquelles il assigne les arguments. Vous voyez que
  désormais les arguments Python sont ceux de cette fonction "impl" ;
  si l'implémentation utilise des noms différents pour ces variables,
  corrigez-les.

  Comme c'est un peu bizarre, ça vaut la peine de répéter. Votre
  fonction doit ressembler à ça :

     static return_type
     your_function_impl(...)
     /*[clinic end generated code: checksum=...]*/
     {
     ...

  Argument Clinic génère une ligne de contrôle et la fonction
  prototype juste au-dessus. Vous devez écrire les accolades
  d'ouverture (et de fermeture) pour la fonction,  et l’implémentation
  à l'intérieur.

  Échantillon :

     /*[clinic input]
     module _pickle
     class _pickle.Pickler "PicklerObject *" "&Pickler_Type"
     [clinic start generated code]*/
     /*[clinic end generated code: checksum=da39a3ee5e6b4b0d3255bfef95601890afd80709]*/

     /*[clinic input]
     _pickle.Pickler.dump

         obj: 'O'
             The object to be pickled.
         /

     Write a pickled representation of obj to the open file.
     [clinic start generated code]*/

     PyDoc_STRVAR(__pickle_Pickler_dump__doc__,
     "Write a pickled representation of obj to the open file.\n"
     "\n"
     ...
     static PyObject *
     _pickle_Pickler_dump_impl(PicklerObject *self, PyObject *obj)
     /*[clinic end generated code: checksum=3bd30745bf206a48f8b576a1da3d90f55a0a4187]*/
     {
         /* Check whether the Pickler was initialized correctly (issue3664).
            Developers often forget to call __init__() in their subclasses, which
            would trigger a segfault without this check. */
         if (self->write == NULL) {
             PyErr_Format(PicklingError,
                          "Pickler.__init__() was not called by %s.__init__()",
                          Py_TYPE(self)->tp_name);
             return NULL;
         }

         if (_Pickler_ClearBuffer(self) < 0)
             return NULL;

         ...

* Vous vous souvenez de la macro avec la structure "PyMethodDef" pour
  cette fonction ? Trouvez la structure "PyMethodDef" existante pour
  cette fonction et remplacez là par une référence à cette macro. (Si
  la fonction native est définie au niveau d'un module, vous le
  trouverez certainement vers la fin du fichier ; s'il s'agit d'une
  méthode de classe, se sera sans doute plus bas, mais relativement
  près de l'implémentation.)

  Notez que le corps de la macro contient une virgule finale. Donc,
  lorsque vous remplacez la structure statique "PyMethodDef" par la
  macro, *n'ajoutez pas* de virgule à la fin.

  Échantillon :

     static struct PyMethodDef Pickler_methods[] = {
         __PICKLE_PICKLER_DUMP_METHODDEF
         __PICKLE_PICKLER_CLEAR_MEMO_METHODDEF
         {NULL, NULL}                /* sentinel */
     };

* Compilez, puis faites tourner les portions idoines de la suite de
  tests de régressions. Ce changement ne doit introduire aucun nouveau
  message d'erreur ou avertissement à la compilation, et il ne devrait
  y avoir aucun changement visible de l'extérieur au comportement de
  Python.

  Enfin, à part pour une différence : si vous exécutez
  "inspect.signature()" sur votre fonction, vous obtiendrez maintenant
  une signature valide !

  Félicitations, vous avez adapté votre première fonction pour qu'elle
  utilise Argument Clinic !


Sujets avancés
==============

Maintenant que vous avez un peu d'expérience avec Argument Clinic,
c'est le moment pour des sujets avancés.


Valeurs par défaut
------------------

La valeur par défaut que vous fournissez pour un paramètre ne peut pas
être n'importe quelle expression. Actuellement, ce qui est géré :

* Constantes numériques (entier ou nombre flottant)

* Chaînes constantes

* "True", "False" et "None"

* Constantes symboliques simples comme "sys.maxsize", qui doivent
  commencer par le nom du module

Si par curiosité vous voulez lire l'implémentation, c'est
"from_builtin()" dans "Lib/inspect.py".

(Dans le futur, il est possible que l'on ait besoin de l'améliorer,
pour autoriser les expressions complètes comme "CONSTANT - 1".)


Renommer les fonctions et variables C générées par Argument Clinic
------------------------------------------------------------------

Argument Clinic nomme automatiquement les fonctions qu'il génère.
Parfois, cela peut poser des problèmes, si le nom généré entre en
collision avec le nom d'une fonction C existante. Il y a une solution
simple : surcharger les noms utilisés par les fonctions C. Ajoutez
simplement le mot clef ""as"" sur la ligne de la déclaration de la
fonction, suivi par le nom de la fonction que vous souhaitez utiliser.
Argument Clinic utilisera ce nom de fonction pour la fonction de base
(celle générée), et ajoutera ""_impl"" à la fin et utilisera ce nom
pour la fonction "impl".

Par exemple, si nous voulons renommer les noms de fonction C générés
pour "pickle.Pickler.dump", ça ressemblerait à ça :

   /*[clinic input]
   pickle.Pickler.dump as pickler_dumper

   ...

La fonction de base sera maintenant nommée "pickler_dumper()", et la
fonction "impl" sera maintenant nommée "pickler_dumper_impl()".

De même, vous pouvez avoir un problème quand vous souhaiterez donner à
un paramètre un nom spécifique à Python, mais ce nom peut être gênant
en C. Argument Clinic vous permet de donner à un paramètre des noms
différents en Python et en C :

   /*[clinic input]
   pickle.Pickler.dump

       obj: object
       file as file_obj: object
       protocol: object = NULL
       *
       fix_imports: bool = True

Ici, le nom utilisé en Python (dans la signature ainsi que le tableau
des "keywords") sera "file", et la variable C s'appellera "file_obj".

Vous pouvez utiliser ceci pour renommer aussi le paramètre "self"


Conversion des fonctions en utilisant *PyArg_UnpackTuple*
---------------------------------------------------------

Afin de convertir une fonction analysant ses arguments via
"PyArg_UnpackTuple()", écrivez simplement tous les arguments, en les
spécifiant comme des "object". Vous pouvez spécifier également le
"type" d'argument afin de le forcer au type approprié. Tous les
arguments devraient être marqués comme seulement positionnels (ajoutez
un "/" seul sur la ligne après le dernier argument).

Actuellement, le code généré utilise "PyArg_ParseTuple()", mais cela
va bientôt changer.


Groupes optionnels
------------------

Certaines fonctions de base ont une approche particulière pour
analyser leurs arguments : elles comptent le nombre d'arguments
positionnels, puis elles utilisent une condition "switch" basée sur le
nombre d'arguments présents pour appeler différentes
"PyArg_ParseTuple()" disponibles (ces fonctions ne peuvent pas avoir
des arguments passés uniquement en tant qu'arguments nommés). Cette
approche était utilisée pour simuler des arguments optionnels avant
que "PyArg_ParseTupleAndKeywords()" ne soit créée.

Alors que les fonctions utilisant cette approche peuvent normalement
être converties pour utiliser "PyArg_ParseTupleAndKeywords()", des
arguments optionnels et des valeurs par défaut, ce n'est pas toujours
possible. Certaines fonctions classiques ne peuvent pas être gérées
par "PyArg_ParseTupleAndKeywords()". L'exemple le plus évident est la
fonction native "range()", qui possède un argument optionnel à
*gauche* de ses arguments requis ! Un autre exemple est la fonction
"curses.window.addch()", qui possède un groupe de deux arguments qui
doivent toujours être spécifiés ensemble (ces arguments s'appellent
"x" et "y" ; si vous appelez la fonction en passant "x", vous devez
passer "y" et si vous ne passez pas "x", vous ne devez pas passer "y"
non plus).

Dans tous les cas, le but d'Argument Clinic est de prendre en charge
l'analyse des arguments pour toutes les fonctions natives de CPython
sans avoir besoin de les modifier. C'est pourquoi Argument Clinic
propose cette autre approche pour l'analyse, en utilisant ce qu'on
appelle les *groupes optionnels*. Les groupes optionnels sont des
groupes d'arguments qui doivent tous être transmis ensemble. Ils
peuvent être situés à droite ou à gauche des arguments requis. Ils ne
peuvent être utilisés *seulement* qu'en tant que paramètres
positionnels.

Note:

  Les groupes optionnels sont *uniquement* prévus pour convertir les
  fonctions faisant des appels multiples à "PyArg_ParseTuple()" ! Les
  fonctions qui utilisent *au moins une* des autres approches ne
  doivent *presque jamais* être converties à Argument Clinic en
  utilisant les groupes optionnels. Les fonctions utilisant ces
  groupes n'ont pas actuellement de signature précise en Python, parce
  que celui-ci ne peut simplement pas comprendre ce concept. Tâchez
  d'éviter au maximum d'utiliser ces groupes optionnels si possible.

Afin de signaler un groupe optionnel, ajoutez un "[" seul sur une
ligne avant les paramètres que vous souhaitez inclure dans le groupe,
puis un "]" seul sur une ligne après ces paramètres. Voici, par
exemple, comment "curses.window.addch" utilise les groupes optionnels
pour rendre optionnel les deux premiers paramètres ainsi que le
dernier :

   /*[clinic input]

   curses.window.addch

       [
       x: int
         X-coordinate.
       y: int
         Y-coordinate.
       ]

       ch: object
         Character to add.

       [
       attr: long
         Attributes for the character.
       ]
       /

   ...

Notes :

* Pour chaque groupe optionnel, un paramètre additionnel sera passé à
  la fonction "impl" représentant le groupe. Ce paramètre sera un
  entier nommé "group_{direction}_{number}", où "{direction}" peut
  être soit "right" ou "left" suivant que le groupe est situé avant ou
  après les paramètres requis, et "{number}" sera un entier incrémenté
  (débutant à 1) indiquant la distance entre le groupe et les
  paramètres requis. Quand la fonction "impl" est appelée, ce
  paramètre est positionné à zéro si le groupe n'a pas été utilisé, et
  positionné à un nombre entier positif sinon (par inutilisé, on
  entend que les paramètres n'ont pas reçu de valeur lors de cet
  appel).

* S'il n'y a pas d'arguments requis, les groupes optionnels se
  comportent comme s'ils étaient à droite des arguments requis.

* En cas d'ambiguïté, le code d'analyse des arguments favorise ceux
  situés à gauche (avant les paramètres obligatoires).

* Les groupes optionnels ne peuvent contenir que des arguments
  positionnels.

* Les groupes optionnels sont *seulement* destinés au code hérité. Ne
  les utilisez pas dans du nouveau code.


Utilisation des adaptateurs d'Argument Clinic, en lieu et place des « adaptateurs de base »
-------------------------------------------------------------------------------------------

Afin de gagner du temps, et pour minimiser la courbe d'apprentissage
pour pouvoir utiliser Argument Clinic, le guide ci-dessus préconise
les « adaptateurs de base ». Ceux-ci sont un moyen simple conçu pour
porter facilement du code existant sous Argument Clinic. Et pour être
clair, leur utilisation est tout à fait acceptable pour porter du code
Python 3.4.

Cependant, sur le long terme, il est certainement préférable que tous
vos blocs utilisent la syntaxe réelle des adaptateurs d'Argument
Clinic. Pourquoi ? Voici quelques raisons :

* Les adaptateurs sont plus simples et plus clairs.

* Il existe des formats qui ne sont pas gérés par les « adaptateurs de
  base », parce qu'ils nécessitent des arguments, et la syntaxe de ces
  adaptateurs ne supporte pas cela.

* Dans le futur, on pourrait avoir une nouvelle bibliothèque d'analyse
  des arguments qui ne serait pas limitée à ce que
  "PyArg_ParseTuple()" accepte ; cette flexibilité ne serait pas
  accessible aux paramètres utilisant des adaptateurs de base.

Ainsi, si vous n'êtes pas contre un petit effort supplémentaire, vous
devriez utiliser les adaptateurs normaux plutôt que ceux de base.

En bref, la syntaxe des adaptateurs d'Argument Clinic ressemble à un
appel de fonction Python. Mais, s'il n'y a pas d'argument explicite à
la fonction (celle-ci utilisant ses valeurs par défaut), vous pouvez
omettre les parenthèses. Ainsi "bool" et "bool()" représentent le même
adaptateur.

Tous les arguments passés aux adaptateurs d'Argument Clinic sont
nommés. Tous les adaptateurs d'Argument Clinic acceptent les arguments
suivants :

   "c_default"
      La valeur par défaut de cet argument lorsqu'il est défini en C.
      Typiquement, il servira à initialiser la variable déclarée dans
      la « fonction d'analyse ». Voir la section relative aux valeurs
      par défaut pour apprendre à l'utiliser. Spécifié en tant que
      chaîne de caractères.

   "annotation"
      La valeur annotée pour ce paramètre. Actuellement non géré, car
      la **PEP 8** exige que les bibliothèques Python n'utilisent pas
      d'annotations.

De plus, certains adaptateurs acceptent des arguments additionnels.
Voici la liste de ces arguments, avec leur explication :

   "accept"
      Un ensemble de types Python (et potentiellement des pseudo-
      types) ; cela restreint l'argument Python autorisé aux valeurs
      de ces types (ce n'est pas destiné à une utilisation généralisée
      ; en fait, il gère seulement les types listés dans la table des
      adaptateurs de base).

      Pour accepter "None", ajouter "NoneType" à cet ensemble.

   "bitwise"
      Autorisé seulement pour les entiers non signés. La valeur native
      de cet argument Python sera transcrite dans le paramètre sans
      aucune vérification de plage, même pour des valeurs négatives.

   "converter"
      Autorisé seulement pour l'adaptateur "object". Spécifie le nom
      d'une « fonction de conversion » depuis C à utiliser pour
      convertir cet objet en type natif.

   "encoding"
      Autorisé seulement pour les chaînes de caractères. Spécifie
      l'encodage à utiliser lors de la conversion de cette chaîne
      depuis une valeur de type Python "str" (Unicode) en valeur C
      "char *".

   "subclass_of"
      Autorisé seulement pour l'adaptateur "object". Nécessite que la
      valeur Python soit une sous-classe d'un type Python, telle
      qu'exprimée en C.

   "type"
      Autorisé seulement pour les adaptateurs "object" et "self".
      Spécifie le type C qui sera utilisé pour déclarer la variable.
      La valeur par défaut est ""PyObject *"".

   "zeroes"
      Autorisé seulement pour les chaînes de caractères. Si vrai, les
      octets NUL ("'\\0'") sont permis au sein de la valeur. La taille
      de la chaîne sera passée à la fonction "impl", juste après le
      paramètre chaîne, en tant que paramètre nommé
      "<parameter_name>_length".

Attention de bien noter que toutes les combinaisons d'arguments ne
fonctionnent pas. Normalement, ces arguments sont mis en place via des
*formats* "PyArg_ParseTuple" au comportement spécifique. Par exemple,
à l'heure actuelle vous ne pouvez pas appeler "unsigned_short" sans
spécifier également "bitwise=True". Bien qu'il soit parfaitement
raisonnable de penser que ça puisse fonctionner, cette écriture ne
correspond à aucun format. Donc Argument Clinic ne le gère pas (en
tous cas, pas pour le moment).

Vous pouvez voir, ci-dessous, une table présentant la correspondance
entre les adaptateurs de base et ceux d'Argument Clinic. À gauche,
sont listés les adaptateurs de base et, à droite, le texte qui les
remplace.

+-----------+-----------------------------------------------------------------------------------+
| "'B'"     | "unsigned_char(bitwise=True)"                                                     |
+-----------+-----------------------------------------------------------------------------------+
| "'b'"     | "unsigned_char"                                                                   |
+-----------+-----------------------------------------------------------------------------------+
| "'c'"     | "char"                                                                            |
+-----------+-----------------------------------------------------------------------------------+
| "'C'"     | "int(accept={str})"                                                               |
+-----------+-----------------------------------------------------------------------------------+
| "'d'"     | "double"                                                                          |
+-----------+-----------------------------------------------------------------------------------+
| "'D'"     | "Py_complex"                                                                      |
+-----------+-----------------------------------------------------------------------------------+
| "'es'"    | "str(encoding='name_of_encoding')"                                                |
+-----------+-----------------------------------------------------------------------------------+
| "'es#'"   | "str(encoding='name_of_encoding', zeroes=True)"                                   |
+-----------+-----------------------------------------------------------------------------------+
| "'et'"    | "str(encoding='name_of_encoding', accept={bytes, bytearray, str})"                |
+-----------+-----------------------------------------------------------------------------------+
| "'et#'"   | "str(encoding='name_of_encoding', accept={bytes, bytearray, str}, zeroes=True)"   |
+-----------+-----------------------------------------------------------------------------------+
| "'f'"     | "float"                                                                           |
+-----------+-----------------------------------------------------------------------------------+
| "'h'"     | "short"                                                                           |
+-----------+-----------------------------------------------------------------------------------+
| "'H'"     | "unsigned_short(bitwise=True)"                                                    |
+-----------+-----------------------------------------------------------------------------------+
| "'i'"     | "int"                                                                             |
+-----------+-----------------------------------------------------------------------------------+
| "'I'"     | "unsigned_int(bitwise=True)"                                                      |
+-----------+-----------------------------------------------------------------------------------+
| "'k'"     | "unsigned_long(bitwise=True)"                                                     |
+-----------+-----------------------------------------------------------------------------------+
| "'K'"     | "unsigned_long_long(bitwise=True)"                                                |
+-----------+-----------------------------------------------------------------------------------+
| "'l'"     | "long"                                                                            |
+-----------+-----------------------------------------------------------------------------------+
| "'L'"     | "long long"                                                                       |
+-----------+-----------------------------------------------------------------------------------+
| "'n'"     | "Py_ssize_t"                                                                      |
+-----------+-----------------------------------------------------------------------------------+
| "'O'"     | "object"                                                                          |
+-----------+-----------------------------------------------------------------------------------+
| "'O!'"    | "object(subclass_of='&PySomething_Type')"                                         |
+-----------+-----------------------------------------------------------------------------------+
| "'O&'"    | "object(converter='name_of_c_function')"                                          |
+-----------+-----------------------------------------------------------------------------------+
| "'p'"     | "bool"                                                                            |
+-----------+-----------------------------------------------------------------------------------+
| "'S'"     | "PyBytesObject"                                                                   |
+-----------+-----------------------------------------------------------------------------------+
| "'s'"     | "str"                                                                             |
+-----------+-----------------------------------------------------------------------------------+
| "'s#'"    | "str(zeroes=True)"                                                                |
+-----------+-----------------------------------------------------------------------------------+
| "'s*'"    | "Py_buffer(accept={buffer, str})"                                                 |
+-----------+-----------------------------------------------------------------------------------+
| "'U'"     | "unicode"                                                                         |
+-----------+-----------------------------------------------------------------------------------+
| "'u'"     | "Py_UNICODE"                                                                      |
+-----------+-----------------------------------------------------------------------------------+
| "'u#'"    | "Py_UNICODE(zeroes=True)"                                                         |
+-----------+-----------------------------------------------------------------------------------+
| "'w*'"    | "Py_buffer(accept={rwbuffer})"                                                    |
+-----------+-----------------------------------------------------------------------------------+
| "'Y'"     | "PyByteArrayObject"                                                               |
+-----------+-----------------------------------------------------------------------------------+
| "'y'"     | "str(accept={bytes})"                                                             |
+-----------+-----------------------------------------------------------------------------------+
| "'y#'"    | "str(accept={robuffer}, zeroes=True)"                                             |
+-----------+-----------------------------------------------------------------------------------+
| "'y*'"    | "Py_buffer"                                                                       |
+-----------+-----------------------------------------------------------------------------------+
| "'Z'"     | "Py_UNICODE(accept={str, NoneType})"                                              |
+-----------+-----------------------------------------------------------------------------------+
| "'Z#'"    | "Py_UNICODE(accept={str, NoneType}, zeroes=True)"                                 |
+-----------+-----------------------------------------------------------------------------------+
| "'z'"     | "str(accept={str, NoneType})"                                                     |
+-----------+-----------------------------------------------------------------------------------+
| "'z#'"    | "str(accept={str, NoneType}, zeroes=True)"                                        |
+-----------+-----------------------------------------------------------------------------------+
| "'z*'"    | "Py_buffer(accept={buffer, str, NoneType})"                                       |
+-----------+-----------------------------------------------------------------------------------+

Par exemple, voici notre code "pickle.Pickler.dump" via l'adaptateur
approprié :

   /*[clinic input]
   pickle.Pickler.dump

       obj: object
           The object to be pickled.
       /

   Write a pickled representation of obj to the open file.
   [clinic start generated code]*/

Un avantage des adaptateurs réels est qu'ils sont plus flexibles que
les adaptateurs de base. Par exemple, l'adaptateur "unsigned_int"
(ainsi que tous les adaptateurs "unsigned_") peut être utilisé sans
"bitwise=True". Leur comportement par défaut contrôle la valeur, et
n'acceptera pas de nombres négatifs. On ne peut pas faire ça avec les
adaptateurs de base !

Argument Clinic sait lister tous les adaptateurs disponibles. Pour
chaque adaptateur, il vous liste également l'ensemble des paramètres
qu'ils acceptent, ainsi que les valeurs par défaut de chacun. Utilisez
simplement la commande "Tools/clinic/clinic.py --converters" pour
afficher la liste.


Py_buffer
---------

Lorsque vous utilisez l'adaptateur "Py_buffer" (ou bien les
adaptateurs de base "'s*'", "'w*'", "'*y'", ou "'z*'"), vous *ne devez
pas* appeler "PyBuffer_Release()" sur le tampon fourni. Argument
Clinic génère du code qui le fait pour vous (dans la fonction
d'analyse).


Adaptateurs avancés
-------------------

Vous vous souvenez de ces spécifications de format que vous avez
laissées de côté la première fois parce qu'il s'agissait de notions
avancées ? Voici comment les utiliser.

L'astuce est que toutes ces spécifications de format acceptent des
arguments — aussi bien des fonctions de conversion que des types, ou
des chaînes spécifiant un encodage. (mais les « adaptateurs de base »
ne gèrent pas les arguments. C'est pourquoi nous les avions laissés de
côté pour votre première fonction.) L'argument que vous aviez spécifié
à la spécification de format est désormais un argument du
convertisseur ; cet argument est soit "converter" (pour "O&"),
"subclass_of" (pour "O!"), ou "encoding" (pour toutes les
spécifications de format qui commencent par "e").

Lorsque vous utilisez "subclass_of", vous pouvez également vouloir
utiliser les autres arguments usuels pour "object()" : "type", qui
vous laisse spécifier le type à utiliser pour l'argument. Par exemple,
si vous voulez vous assurer que l'objet est une sous-classe de
"PyUnicode_Type", vous utiliserez probablement le convertisseur
"object(type='PyUnicodeObject *', subclass_of='&PyUnicode_Type')".

Mentionnons un problème potentiel d'utiliser *Argument Clinic* : cela
retire la flexibilité des spécifications de format commençant par "e".
Lorsque vous faites un appel à "PyArg_Parse" à la main, vous pourriez
théoriquement décider quelle chaîne d'encodage passer à
"PyArg_ParseTuple()". Mais désormais cette chaîne doit être codée en
dur au moment du pré-processus d'Argument-Clinic. Cette limitation est
délibérée ; elle permet une gestion plus simple de cette spécification
de format, et peut permettre de futures optimisations. Cette
restriction ne semble pas déraisonnable ; CPython lui-même utilise
toujours des chaînes d'encodage en dur pour les paramètres dont les
spécifications de format commencent par "e".


Valeurs par défaut des paramètres
---------------------------------

Les valeurs par défaut des paramètres peuvent être n'importe quelle
valeur. Au plus simple, ce sont des chaînes, des entiers ou des
nombres flottants :

   foo: str = "abc"
   bar: int = 123
   bat: float = 45.6

Vous pouvez également utiliser n'importe quelle constante native de
Python :

   yep:  bool = True
   nope: bool = False
   nada: object = None

La valeur "NULL" est également acceptée, ainsi que des expressions
simples, comme expliqué dans les sections suivantes.


La valeur par défaut "NULL"
---------------------------

Pour les paramètres chaînes et objets, vous pouvez les positionner à
"None" pour indiquer qu'il n'y a pas de valeur par défaut. Pour
autant, cela signifie que la variable C sera initialisée à "Py_None".
Par commodité, il existe une valeur spécifique appelée "NULL" juste
pour cette raison : du point de vue de Python, cette valeur se
comporte comme la valeur par défaut "None", mais la variable C est
initialisée à "NULL".


Expressions spécifiées comme valeurs par défaut
-----------------------------------------------

La valeur par défaut d'un paramètre peut être plus qu'une simple
valeur littérale. Il peut s'agir d'une expression, utilisant des
opérateurs mathématiques et des attributs d'objets. Cependant, cette
possibilité n'est pas aussi simple, notamment à cause de sémantiques
peu évidentes.

Examinons l'exemple suivant :

   foo: Py_ssize_t = sys.maxsize - 1

"sys.maxsize" can have different values on different platforms.
Therefore Argument Clinic can't simply evaluate that expression
locally and hard-code it in C.  So it stores the default in such a way
that it will get evaluated at runtime, when the user asks for the
function's signature.

What namespace is available when the expression is evaluated?  It's
evaluated in the context of the module the builtin came from.  So, if
your module has an attribute called ""max_widgets"", you may simply
use it:

   foo: Py_ssize_t = max_widgets

If the symbol isn't found in the current module, it fails over to
looking in "sys.modules".  That's how it can find "sys.maxsize" for
example.  (Since you don't know in advance what modules the user will
load into their interpreter, it's best to restrict yourself to modules
that are preloaded by Python itself.)

Evaluating default values only at runtime means Argument Clinic can't
compute the correct equivalent C default value.  So you need to tell
it explicitly. When you use an expression, you must also specify the
equivalent expression in C, using the "c_default" parameter to the
converter:

   foo: Py_ssize_t(c_default="PY_SSIZE_T_MAX - 1") = sys.maxsize - 1

Another complication: Argument Clinic can't know in advance whether or
not the expression you supply is valid.  It parses it to make sure it
looks legal, but it can't *actually* know.  You must be very careful
when using expressions to specify values that are guaranteed to be
valid at runtime!

Finally, because expressions must be representable as static C values,
there are many restrictions on legal expressions.  Here's a list of
Python features you're not permitted to use:

* des appels de fonction.

* des instructions *if* en ligne ("3 if foo else 5") ;

* Automatic sequence unpacking ("*[1, 2, 3]").

* List/set/dict comprehensions and generator expressions.

* Tuple/list/set/dict literals.


Using a return converter
------------------------

By default the impl function Argument Clinic generates for you returns
"PyObject *". But your C function often computes some C type, then
converts it into the "PyObject *" at the last moment.  Argument Clinic
handles converting your inputs from Python types into native C
types—why not have it convert your return value from a native C type
into a Python type too?

That's what a "return converter" does.  It changes your impl function
to return some C type, then adds code to the generated (non-impl)
function to handle converting that value into the appropriate
"PyObject *".

The syntax for return converters is similar to that of parameter
converters. You specify the return converter like it was a return
annotation on the function itself.  Return converters behave much the
same as parameter converters; they take arguments, the arguments are
all keyword-only, and if you're not changing any of the default
arguments you can omit the parentheses.

(If you use both ""as"" *and* a return converter for your function,
the ""as"" should come before the return converter.)

There's one additional complication when using return converters: how
do you indicate an error has occurred?  Normally, a function returns a
valid (non-"NULL") pointer for success, and "NULL" for failure.  But
if you use an integer return converter, all integers are valid.  How
can Argument Clinic detect an error?  Its solution: each return
converter implicitly looks for a special value that indicates an
error.  If you return that value, and an error has been set
("PyErr_Occurred()" returns a true value), then the generated code
will propagate the error.  Otherwise it will encode the value you
return like normal.

Currently Argument Clinic supports only a few return converters:

   bool
   int
   unsigned int
   long
   unsigned int
   size_t
   Py_ssize_t
   float
   double
   DecodeFSDefault

None of these take parameters.  For the first three, return -1 to
indicate error.  For "DecodeFSDefault", the return type is "const char
*"; return a "NULL" pointer to indicate an error.

(There's also an experimental "NoneType" converter, which lets you
return "Py_None" on success or "NULL" on failure, without having to
increment the reference count on "Py_None".  I'm not sure it adds
enough clarity to be worth using.)

To see all the return converters Argument Clinic supports, along with
their parameters (if any), just run "Tools/clinic/clinic.py
--converters" for the full list.


Cloning existing functions
--------------------------

If you have a number of functions that look similar, you may be able
to use Clinic's "clone" feature.  When you clone an existing function,
you reuse:

* its parameters, including

  * their names,

  * their converters, with all parameters,

  * their default values,

  * their per-parameter docstrings,

  * their *kind* (whether they're positional only, positional or
    keyword, or keyword only), and

* its return converter.

The only thing not copied from the original function is its docstring;
the syntax allows you to specify a new docstring.

Here's the syntax for cloning a function:

   /*[clinic input]
   module.class.new_function [as c_basename] = module.class.existing_function

   Docstring for new_function goes here.
   [clinic start generated code]*/

(The functions can be in different modules or classes.  I wrote
"module.class" in the sample just to illustrate that you must use the
full path to *both* functions.)

Sorry, there's no syntax for partially-cloning a function, or cloning
a function then modifying it.  Cloning is an all-or nothing
proposition.

Also, the function you are cloning from must have been previously
defined in the current file.


Calling Python code
-------------------

The rest of the advanced topics require you to write Python code which
lives inside your C file and modifies Argument Clinic's runtime state.
This is simple: you simply define a Python block.

A Python block uses different delimiter lines than an Argument Clinic
function block.  It looks like this:

   /*[python input]
   # python code goes here
   [python start generated code]*/

All the code inside the Python block is executed at the time it's
parsed.  All text written to stdout inside the block is redirected
into the "output" after the block.

As an example, here's a Python block that adds a static integer
variable to the C code:

   /*[python input]
   print('static int __ignored_unused_variable__ = 0;')
   [python start generated code]*/
   static int __ignored_unused_variable__ = 0;
   /*[python checksum:...]*/


Using a "self converter"
------------------------

Argument Clinic automatically adds a "self" parameter for you using a
default converter.  It automatically sets the "type" of this parameter
to the "pointer to an instance" you specified when you declared the
type.  However, you can override Argument Clinic's converter and
specify one yourself. Just add your own "self" parameter as the first
parameter in a block, and ensure that its converter is an instance of
"self_converter" or a subclass thereof.

What's the point?  This lets you override the type of "self", or give
it a different default name.

How do you specify the custom type you want to cast "self" to? If you
only have one or two functions with the same type for "self", you can
directly use Argument Clinic's existing "self" converter, passing in
the type you want to use as the "type" parameter:

   /*[clinic input]

   _pickle.Pickler.dump

     self: self(type="PicklerObject *")
     obj: object
     /

   Write a pickled representation of the given object to the open file.
   [clinic start generated code]*/

On the other hand, if you have a lot of functions that will use the
same type for "self", it's best to create your own converter,
subclassing "self_converter" but overwriting the "type" member:

   /*[python input]
   class PicklerObject_converter(self_converter):
       type = "PicklerObject *"
   [python start generated code]*/

   /*[clinic input]

   _pickle.Pickler.dump

     self: PicklerObject
     obj: object
     /

   Write a pickled representation of the given object to the open file.
   [clinic start generated code]*/


Writing a custom converter
--------------------------

As we hinted at in the previous section... you can write your own
converters! A converter is simply a Python class that inherits from
"CConverter". The main purpose of a custom converter is if you have a
parameter using the "O&" format unit—parsing this parameter means
calling a "PyArg_ParseTuple()" "converter function".

Your converter class should be named "*something*_converter". If the
name follows this convention, then your converter class will be
automatically registered with Argument Clinic; its name will be the
name of your class with the "_converter" suffix stripped off.  (This
is accomplished with a metaclass.)

You shouldn't subclass "CConverter.__init__".  Instead, you should
write a "converter_init()" function.  "converter_init()" always
accepts a "self" parameter; after that, all additional parameters
*must* be keyword-only.  Any arguments passed in to the converter in
Argument Clinic will be passed along to your "converter_init()".

There are some additional members of "CConverter" you may wish to
specify in your subclass.  Here's the current list:

"type"
   The C type to use for this variable. "type" should be a Python
   string specifying the type, e.g. "int". If this is a pointer type,
   the type string should end with "' *'".

"default"
   The Python default value for this parameter, as a Python value. Or
   the magic value "unspecified" if there is no default.

"py_default"
   "default" as it should appear in Python code, as a string. Or
   "None" if there is no default.

"c_default"
   "default" as it should appear in C code, as a string. Or "None" if
   there is no default.

"c_ignored_default"
   The default value used to initialize the C variable when there is
   no default, but not specifying a default may result in an
   "uninitialized variable" warning.  This can easily happen when
   using option groups—although properly-written code will never
   actually use this value, the variable does get passed in to the
   impl, and the C compiler will complain about the "use" of the
   uninitialized value.  This value should always be a non-empty
   string.

"converter"
   The name of the C converter function, as a string.

"impl_by_reference"
   A boolean value.  If true, Argument Clinic will add a "&" in front
   of the name of the variable when passing it into the impl function.

"parse_by_reference"
   A boolean value.  If true, Argument Clinic will add a "&" in front
   of the name of the variable when passing it into
   "PyArg_ParseTuple()".

Here's the simplest example of a custom converter, from
"Modules/zlibmodule.c":

   /*[python input]

   class ssize_t_converter(CConverter):
       type = 'Py_ssize_t'
       converter = 'ssize_t_converter'

   [python start generated code]*/
   /*[python end generated code: output=da39a3ee5e6b4b0d input=35521e4e733823c7]*/

This block adds a converter to Argument Clinic named "ssize_t".
Parameters declared as "ssize_t" will be declared as type
"Py_ssize_t", and will be parsed by the "'O&'" format unit, which will
call the "ssize_t_converter" converter function.  "ssize_t" variables
automatically support default values.

More sophisticated custom converters can insert custom C code to
handle initialization and cleanup. You can see more examples of custom
converters in the CPython source tree; grep the C files for the string
"CConverter".


Writing a custom return converter
---------------------------------

Writing a custom return converter is much like writing a custom
converter.  Except it's somewhat simpler, because return converters
are themselves much simpler.

Return converters must subclass "CReturnConverter". There are no
examples yet of custom return converters, because they are not widely
used yet.  If you wish to write your own return converter, please read
"Tools/clinic/clinic.py", specifically the implementation of
"CReturnConverter" and all its subclasses.


METH_O and METH_NOARGS
----------------------

To convert a function using "METH_O", make sure the function's single
argument is using the "object" converter, and mark the arguments as
positional-only:

   /*[clinic input]
   meth_o_sample

        argument: object
        /
   [clinic start generated code]*/

To convert a function using "METH_NOARGS", just don't specify any
arguments.

You can still use a self converter, a return converter, and specify a
"type" argument to the object converter for "METH_O".


tp_new and tp_init functions
----------------------------

You can convert "tp_new" and "tp_init" functions.  Just name them
"__new__" or "__init__" as appropriate.  Notes:

* The function name generated for "__new__" doesn't end in "__new__"
  like it would by default.  It's just the name of the class,
  converted into a valid C identifier.

* No "PyMethodDef" "#define" is generated for these functions.

* "__init__" functions return "int", not "PyObject *".

* Use the docstring as the class docstring.

* Although "__new__" and "__init__" functions must always accept both
  the "args" and "kwargs" objects, when converting you may specify any
  signature for these functions that you like. (If your function
  doesn't support keywords, the parsing function generated will throw
  an exception if it receives any.)


Changing and redirecting Clinic's output
----------------------------------------

It can be inconvenient to have Clinic's output interspersed with your
conventional hand-edited C code.  Luckily, Clinic is configurable: you
can buffer up its output for printing later (or earlier!), or write
its output to a separate file.  You can also add a prefix or suffix to
every line of Clinic's generated output.

While changing Clinic's output in this manner can be a boon to
readability, it may result in Clinic code using types before they are
defined, or your code attempting to use Clinic-generated code before
it is defined. These problems can be easily solved by rearranging the
declarations in your file, or moving where Clinic's generated code
goes.  (This is why the default behavior of Clinic is to output
everything into the current block; while many people consider this
hampers readability, it will never require rearranging your code to
fix definition-before-use problems.)

Let's start with defining some terminology:

*field*
   A field, in this context, is a subsection of Clinic's output. For
   example, the "#define" for the "PyMethodDef" structure is a field,
   called "methoddef_define".  Clinic has seven different fields it
   can output per function definition:

      docstring_prototype
      docstring_definition
      methoddef_define
      impl_prototype
      parser_prototype
      parser_definition
      impl_definition

   All the names are of the form ""<a>_<b>"", where ""<a>"" is the
   semantic object represented (the parsing function, the impl
   function, the docstring, or the methoddef structure) and ""<b>""
   represents what kind of statement the field is.  Field names that
   end in ""_prototype"" represent forward declarations of that thing,
   without the actual body/data of the thing; field names that end in
   ""_definition"" represent the actual definition of the thing, with
   the body/data of the thing.  (""methoddef"" is special, it's the
   only one that ends with ""_define"", representing that it's a
   preprocessor #define.)

*destination*
   A destination is a place Clinic can write output to.  There are
   five built-in destinations:

   "block"
      The default destination: printed in the output section of the
      current Clinic block.

   "buffer"
      A text buffer where you can save text for later.  Text sent here
      is appended to the end of any existing text.  It's an error to
      have any text left in the buffer when Clinic finishes processing
      a file.

   "file"
      A separate "clinic file" that will be created automatically by
      Clinic. The filename chosen for the file is
      "{basename}.clinic{extension}", where "basename" and "extension"
      were assigned the output from "os.path.splitext()" run on the
      current file.  (Example: the "file" destination for "_pickle.c"
      would be written to "_pickle.clinic.c".)

      **Important: When using a** "file" **destination, you** *must
      check in* **the generated file!**

   "two-pass"
      A buffer like "buffer".  However, a two-pass buffer can only be
      dumped once, and it prints out all text sent to it during all
      processing, even from Clinic blocks *after* the dumping point.

   "suppress"
      The text is suppressed—thrown away.

Clinic defines five new directives that let you reconfigure its
output.

The first new directive is "dump":

   dump <destination>

This dumps the current contents of the named destination into the
output of the current block, and empties it.  This only works with
"buffer" and "two-pass" destinations.

The second new directive is "output".  The most basic form of "output"
is like this:

   output <field> <destination>

This tells Clinic to output *field* to *destination*.  "output" also
supports a special meta-destination, called "everything", which tells
Clinic to output *all* fields to that *destination*.

"output" has a number of other functions:

   output push
   output pop
   output preset <preset>

"output push" and "output pop" allow you to push and pop
configurations on an internal configuration stack, so that you can
temporarily modify the output configuration, then easily restore the
previous configuration.  Simply push before your change to save the
current configuration, then pop when you wish to restore the previous
configuration.

"output preset" sets Clinic's output to one of several built-in preset
configurations, as follows:

   "block"
      Clinic's original starting configuration.  Writes everything
      immediately after the input block.

      Suppress the "parser_prototype" and "docstring_prototype", write
      everything else to "block".

   "file"
      Designed to write everything to the "clinic file" that it can.
      You then "#include" this file near the top of your file. You may
      need to rearrange your file to make this work, though usually
      this just means creating forward declarations for various
      "typedef" and "PyTypeObject" definitions.

      Suppress the "parser_prototype" and "docstring_prototype", write
      the "impl_definition" to "block", and write everything else to
      "file".

      The default filename is ""{dirname}/clinic/{basename}.h"".

   "buffer"
      Save up most of the output from Clinic, to be written into your
      file near the end.  For Python files implementing modules or
      builtin types, it's recommended that you dump the buffer just
      above the static structures for your module or builtin type;
      these are normally very near the end.  Using "buffer" may
      require even more editing than "file", if your file has static
      "PyMethodDef" arrays defined in the middle of the file.

      Suppress the "parser_prototype", "impl_prototype", and
      "docstring_prototype", write the "impl_definition" to "block",
      and write everything else to "file".

   "two-pass"
      Similar to the "buffer" preset, but writes forward declarations
      to the "two-pass" buffer, and definitions to the "buffer". This
      is similar to the "buffer" preset, but may require less editing
      than "buffer".  Dump the "two-pass" buffer near the top of your
      file, and dump the "buffer" near the end just like you would
      when using the "buffer" preset.

      Suppresses the "impl_prototype", write the "impl_definition" to
      "block", write "docstring_prototype", "methoddef_define", and
      "parser_prototype" to "two-pass", write everything else to
      "buffer".

   "partial-buffer"
      Similar to the "buffer" preset, but writes more things to
      "block", only writing the really big chunks of generated code to
      "buffer". This avoids the definition-before-use problem of
      "buffer" completely, at the small cost of having slightly more
      stuff in the block's output. Dump the "buffer" near the end,
      just like you would when using the "buffer" preset.

      Suppresses the "impl_prototype", write the
      "docstring_definition" and "parser_definition" to "buffer",
      write everything else to "block".

The third new directive is "destination":

   destination <name> <command> [...]

This performs an operation on the destination named "name".

There are two defined subcommands: "new" and "clear".

The "new" subcommand works like this:

   destination <name> new <type>

This creates a new destination with name "<name>" and type "<type>".

There are five destination types:

   "suppress"
      Throws the text away.

   "block"
      Writes the text to the current block.  This is what Clinic
      originally did.

   "buffer"
      A simple text buffer, like the "buffer" builtin destination
      above.

   "file"
      A text file.  The file destination takes an extra argument, a
      template to use for building the filename, like so:

         destination <name> new <type> <file_template>

      The template can use three strings internally that will be
      replaced by bits of the filename:

         {path}
            The full path to the file, including directory and full
            filename.

         {dirname}
            The name of the directory the file is in.

         {basename}
            Just the name of the file, not including the directory.

         {basename_root}
            Basename with the extension clipped off (everything up to
            but not including the last '.').

         {basename_extension}
            The last '.' and everything after it.  If the basename
            does not contain a period, this will be the empty string.

      If there are no periods in the filename, {basename} and
      {filename} are the same, and {extension} is empty.
      "{basename}{extension}" is always exactly the same as
      "{filename}"."

   "two-pass"
      A two-pass buffer, like the "two-pass" builtin destination
      above.

The "clear" subcommand works like this:

   destination <name> clear

It removes all the accumulated text up to this point in the
destination. (I don't know what you'd need this for, but I thought
maybe it'd be useful while someone's experimenting.)

The fourth new directive is "set":

   set line_prefix "string"
   set line_suffix "string"

"set" lets you set two internal variables in Clinic. "line_prefix" is
a string that will be prepended to every line of Clinic's output;
"line_suffix" is a string that will be appended to every line of
Clinic's output.

Both of these support two format strings:

   "{block comment start}"
      Turns into the string "/*", the start-comment text sequence for
      C files.

   "{block comment end}"
      Turns into the string "*/", the end-comment text sequence for C
      files.

The final new directive is one you shouldn't need to use directly,
called "preserve":

   preserve

This tells Clinic that the current contents of the output should be
kept, unmodified. This is used internally by Clinic when dumping
output into "file" files; wrapping it in a Clinic block lets Clinic
use its existing checksum functionality to ensure the file was not
modified by hand before it gets overwritten.


The #ifdef trick
----------------

If you're converting a function that isn't available on all platforms,
there's a trick you can use to make life a little easier.  The
existing code probably looks like this:

   #ifdef HAVE_FUNCTIONNAME
   static module_functionname(...)
   {
   ...
   }
   #endif /* HAVE_FUNCTIONNAME */

And then in the "PyMethodDef" structure at the bottom the existing
code will have:

   #ifdef HAVE_FUNCTIONNAME
   {'functionname', ... },
   #endif /* HAVE_FUNCTIONNAME */

In this scenario, you should enclose the body of your impl function
inside the "#ifdef", like so:

   #ifdef HAVE_FUNCTIONNAME
   /*[clinic input]
   module.functionname
   ...
   [clinic start generated code]*/
   static module_functionname(...)
   {
   ...
   }
   #endif /* HAVE_FUNCTIONNAME */

Then, remove those three lines from the "PyMethodDef" structure,
replacing them with the macro Argument Clinic generated:

   MODULE_FUNCTIONNAME_METHODDEF

(You can find the real name for this macro inside the generated code.
Or you can calculate it yourself: it's the name of your function as
defined on the first line of your block, but with periods changed to
underscores, uppercased, and ""_METHODDEF"" added to the end.)

Perhaps you're wondering: what if "HAVE_FUNCTIONNAME" isn't defined?
The "MODULE_FUNCTIONNAME_METHODDEF" macro won't be defined either!

Here's where Argument Clinic gets very clever.  It actually detects
that the Argument Clinic block might be deactivated by the "#ifdef".
When that happens, it generates a little extra code that looks like
this:

   #ifndef MODULE_FUNCTIONNAME_METHODDEF
       #define MODULE_FUNCTIONNAME_METHODDEF
   #endif /* !defined(MODULE_FUNCTIONNAME_METHODDEF) */

That means the macro always works.  If the function is defined, this
turns into the correct structure, including the trailing comma.  If
the function is undefined, this turns into nothing.

However, this causes one ticklish problem: where should Argument
Clinic put this extra code when using the "block" output preset?  It
can't go in the output block, because that could be deactivated by the
"#ifdef".  (That's the whole point!)

In this situation, Argument Clinic writes the extra code to the
"buffer" destination. This may mean that you get a complaint from
Argument Clinic:

   Warning in file "Modules/posixmodule.c" on line 12357:
   Destination buffer 'buffer' not empty at end of file, emptying.

When this happens, just open your file, find the "dump buffer" block
that Argument Clinic added to your file (it'll be at the very bottom),
then move it above the "PyMethodDef" structure where that macro is
used.


Using Argument Clinic in Python files
-------------------------------------

It's actually possible to use Argument Clinic to preprocess Python
files. There's no point to using Argument Clinic blocks, of course, as
the output wouldn't make any sense to the Python interpreter.  But
using Argument Clinic to run Python blocks lets you use Python as a
Python preprocessor!

Since Python comments are different from C comments, Argument Clinic
blocks embedded in Python files look slightly different.  They look
like this:

   #/*[python input]
   #print("def foo(): pass")
   #[python start generated code]*/
   def foo(): pass
   #/*[python checksum:...]*/
