Guide Argument Clinic¶
- auteur
Larry Hastings
Source code: Tools/clinic/clinic.py.
Résumé
Argument Clinic is a preprocessor for CPython C files. It was introduced in Python 3.4 with PEP 436, in order to provide introspection signatures, and to generate performant and tailor-made boilerplate code for argument parsing in CPython builtins, module level functions, and class methods. This document is divided in four major sections:
Background talks about the basic concepts and goals of Argument Clinic.
Reference describes the command-line interface and Argument Clinic terminology.
Tutorial guides you through all the steps required to adapt an existing C function to Argument Clinic.
How-to guides details how to handle specific tasks.
Note
Argument Clinic is considered internal-only for CPython. Its use is not supported for files outside CPython, and no guarantees are made regarding backwards compatibility for future versions. In other words: if you maintain an external C extension for CPython, you're welcome to experiment with Argument Clinic in your own code. But the version of Argument Clinic that ships with the next version of CPython could be totally incompatible and break all your code.
Background¶
Basic concepts¶
When Argument Clinic is run on a file, either via the Command-line interface
or via make clinic
, it will scan over the input files looking for
start lines:
/*[clinic input]
When it finds one, it reads everything up to the end line:
[clinic start generated code]*/
Everything in between these two lines is Argument Clinic input. When Argument Clinic parses input, it generates output. The output is rewritten into the C file immediately after the input, followed by a checksum line. All of these lines, including the start line and checksum line, are collectively called an Argument Clinic block:
/*[clinic input]
... clinic input goes here ...
[clinic start generated code]*/
... clinic output goes here ...
/*[clinic end generated code: ...]*/
If you run Argument Clinic on the same file a second time, Argument Clinic will discard the old output and write out the new output with a fresh checksum line. If the input hasn't changed, the output won't change either.
Note
You should never modify the output of an Argument Clinic block, as any change will be lost in future Argument Clinic runs; Argument Clinic will detect an output checksum mismatch and regenerate the correct output. If you are not happy with the generated output, you should instead change the input until it produces the output you want.
Reference¶
Terminology¶
- start line¶
The line
/*[clinic input]
. This line marks the beginning of Argument Clinic input. Note that the start line opens a C block comment.- end line¶
The line
[clinic start generated code]*/
. The end line marks the _end_ of Argument Clinic input, but at the same time marks the _start_ of Argument Clinic output, thus the text "clinic start start generated code" Note that the end line closes the C block comment opened by the start line.- checksum¶
- checksum line¶
A line that looks like
/*[clinic end generated code: ...]*/
. The three dots will be replaced by a checksum generated from the input, and a checksum generated from the output. The checksum line marks the end of Argument Clinic generated code, and is used by Argument Clinic to determine if it needs to regenerate output.- input¶
The text between the start line and the end line. Note that the start and end lines open and close a C block comment; the input is thus a part of that same C block comment.
- output¶
The text between the end line and the checksum line.
- block¶
All text from the start line to the checksum line inclusively.
Command-line interface¶
The Argument Clinic CLI is typically used to process a single source file, like this:
$ python3 ./Tools/clinic/clinic.py foo.c
The CLI supports the following options:
- -h, --help¶
Print CLI usage.
- -f, --force¶
Force output regeneration.
- -o, --output OUTPUT¶
Redirect file output to OUTPUT
- -v, --verbose¶
Enable verbose mode.
- --converters¶
Print a list of all supported converters and return converters.
- FILE ...¶
The list of files to process.
Classes for extending Argument Clinic¶
- class clinic.CConverter¶
The base class for all converters. See How to write a custom converter for how to subclass this class.
- 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. OrNone
if there is no default.
- c_default¶
default
as it should appear in C code, as a string. OrNone
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 intoPyArg_ParseTuple()
.
Tutorial¶
The best way to get a sense of how Argument Clinic works is to convert a function to work with it. Here, then, are the bare minimum steps you'd need to follow to convert a function to work with Argument Clinic. Note that for code you plan to check in to CPython, you really should take the conversion farther, using some of the advanced concepts you'll see later on in the document, like How to use return converters and How to use the "self converter". But we'll keep it simple for this walkthrough so you can learn.
First, make sure you're working with a freshly updated checkout of the CPython trunk.
Next, find a Python builtin that calls either PyArg_ParseTuple()
or PyArg_ParseTupleAndKeywords()
, and hasn't been converted
to work with Argument Clinic yet.
For this tutorial, we'll be using
_pickle.Pickler.dump
.
If the call to the PyArg_Parse*()
function uses any of the
following format units...:
O& O! es es# et et#
... or if it has multiple calls to PyArg_ParseTuple()
,
you should choose a different function.
(See How to use advanced converters for those scenarios.)
Also, if the function has multiple calls to PyArg_ParseTuple()
or PyArg_ParseTupleAndKeywords()
where it supports different
types for the same argument, or if the function uses something besides
PyArg_Parse*()
functions to parse its arguments, it probably
isn't suitable for conversion to Argument Clinic. Argument Clinic
doesn't support generic functions or polymorphic parameters.
Next, add the following boilerplate above the function, creating our input block:
/*[clinic input]
[clinic start generated code]*/
Cut the docstring and paste it in between the [clinic]
lines,
removing all the junk that makes it a properly quoted C string.
When you're done you should have just the text, based at the left
margin, with no line wider than 80 characters.
Argument Clinic will preserve indents inside the docstring.
If the old docstring had a first line that looked like a function
signature, throw that line away; The docstring doesn't need it anymore ---
when you use help()
on your builtin in the future,
the first line will be built automatically based on the function's signature.
Example docstring summary line:
/*[clinic input]
Write a pickled representation of obj to the open file.
[clinic start generated code]*/
If your docstring doesn't have a "summary" line, Argument Clinic will complain, so let's make sure it has one. The "summary" line should be a paragraph consisting of a single 80-column line at the beginning of the docstring. (See PEP 257 regarding docstring conventions.)
Our example docstring consists solely of a summary line, so the sample code doesn't have to change for this step.
Now, above the docstring, enter the name of the function, followed by a blank line. This should be the Python name of the function, and should be the full dotted path to the function --- it should start with the name of the module, include any sub-modules, and if the function is a method on a class it should include the class name too.
In our example, _pickle
is the module, Pickler
is the class,
and dump()
is the method, so the name becomes
_pickle.Pickler.dump()
:
/*[clinic input]
_pickle.Pickler.dump
Write a pickled representation of obj to the open file.
[clinic start generated code]*/
If this is the first time that module or class has been used with Argument Clinic in this C file, you must declare the module and/or class. Proper Argument Clinic hygiene prefers declaring these in a separate block somewhere near the top of the C file, in the same way that include files and statics go at the top. In our sample code we'll just show the two blocks next to each other.
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
When you declare a class, you must also specify two aspects of its type
in C: the type declaration you'd use for a pointer to an instance of
this class, and a pointer to the PyTypeObject
for this class:
/*[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]*/
Declare each of the parameters to the function. Each parameter should get its own line. All the parameter lines should be indented from the function name and the docstring. The general form of these parameter lines is as follows:
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's support for "default values" is quite sophisticated; see How to assign default values to parameter for more information.
Next, add a blank line below the parameters.
What's a "converter"? It establishes both the type of the variable used in C, and the method to convert the Python value into a C value at runtime. For now you're going to use what's called a "legacy converter" --- a convenience syntax intended to make porting old code into Argument Clinic easier.
For each parameter, copy the "format unit" for that
parameter from the PyArg_Parse()
format argument and
specify that as its converter, as a quoted string.
The "format unit" is the formal name for the one-to-three
character substring of the format parameter that tells
the argument parsing function what the type of the variable
is and how to convert it.
For more on format units please see 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]*/
If your function has |
in the format string,
meaning some parameters have default values, you can ignore it.
Argument Clinic infers which parameters are optional
based on whether or not they have default values.
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()
has neither, so our sample is unchanged.
Next, if the existing C function calls PyArg_ParseTuple()
(as opposed to PyArg_ParseTupleAndKeywords()
), then all its
arguments are positional-only.
To mark parameters as positional-only in Argument Clinic,
add a /
on a line by itself after the last positional-only parameter,
indented the same as the parameter lines.
É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]*/
It can be helpful to write a per-parameter docstring for each parameter. Since per-parameter docstrings are optional, you can skip this step if you prefer.
Nevertheless, here's how to add a per-parameter docstring. The first line of the per-parameter docstring must be indented further than the parameter definition. The left margin of this first line establishes the left margin for the whole per-parameter docstring; all the text you write will be outdented by this amount. You can write as much text as you like, across multiple lines if you wish.
É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]*/
Save and close the file, then run Tools/clinic/clinic.py
on it.
With luck everything worked---your block now has output,
and a .c.h
file has been generated!
Reload the file in your text editor to see the 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]*/
static PyObject *
_pickle_Pickler_dump(PicklerObject *self, PyObject *obj)
/*[clinic end generated code: output=87ecad1261e02ac7 input=552eb1c0f52260d9]*/
Obviously, if Argument Clinic didn't produce any output, it's because it found an error in your input. Keep fixing your errors and retrying until Argument Clinic processes your file without complaint.
For readability, most of the glue code has been generated to a .c.h
file. You'll need to include that in your original .c
file,
typically right after the clinic module block:
#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.
Second, the format string passed in to PyArg_ParseTuple()
or
PyArg_ParseTupleAndKeywords()
should be exactly the same
as the hand-written one in the existing function,
up to the colon or semi-colon.
Argument Clinic always generates its format strings
with a :
followed by the name of the function.
If the existing code's format string ends with ;
,
to provide usage help, this change is harmless --- don't worry about it.
Third, for parameters whose format units require two arguments, like a length variable, an encoding string, or a pointer to a conversion function, ensure that the second argument is exactly the same between the two invocations.
Fourth, inside the output portion of the block,
you'll find a preprocessor macro defining the appropriate static
PyMethodDef
structure for this builtin:
#define __PICKLE_PICKLER_DUMP_METHODDEF \
{"dump", (PyCFunction)__pickle_Pickler_dump, METH_O, __pickle_Pickler_dump__doc__},
This static structure should be exactly the same as the existing static
PyMethodDef
structure for this builtin.
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.
Let's reiterate, just because it's kind of weird. Your code should now look like this:
static return_type
your_function_impl(...)
/*[clinic end generated code: input=..., output=...]*/
{
...
Argument Clinic generated the checksum line and the function prototype just above it. You should write the opening and closing curly braces for the function, and the implementation inside.
É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;
}
...
Remember the macro with the PyMethodDef
structure for this function?
Find the existing PyMethodDef
structure for this
function and replace it with a reference to the macro. If the builtin
is at module scope, this will probably be very near the end of the file;
if the builtin is a class method, this will probably be below but relatively
near to the implementation.
Note that the body of the macro contains a trailing comma; when you
replace the existing static PyMethodDef
structure with the macro,
don't add a comma to the end.
Échantillon :
static struct PyMethodDef Pickler_methods[] = {
__PICKLE_PICKLER_DUMP_METHODDEF
__PICKLE_PICKLER_CLEAR_MEMO_METHODDEF
{NULL, NULL} /* sentinel */
};
Finally, compile, then run the relevant portions of the regression-test suite.
This change should not introduce any new compile-time warnings or errors,
and there should be no externally visible change to Python's behavior,
except for one difference: inspect.signature()
run on your function
should now provide a valid signature!
Félicitations, vous avez adapté votre première fonction pour qu'elle utilise Argument Clinic !
How-to guides¶
How to rename C functions and variables generated by 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
.
For example, if we wanted to rename the C function names generated for
pickle.Pickler.dump()
, it'd look like this:
/*[clinic input]
pickle.Pickler.dump as pickler_dumper
...
The base function would now be named pickler_dumper()
,
and the impl function would now be named 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
Here, the name used in Python (in the signature and the keywords
array) would be file, but the C variable would be named file_obj
.
You can use this to rename the self parameter too!
How to convert functions using PyArg_UnpackTuple
¶
To convert a function parsing its arguments with PyArg_UnpackTuple()
,
simply write out all the arguments, specifying each as an object
. You
may specify the type argument to cast the type as appropriate. All
arguments should be marked positional-only (add a /
on a line by itself
after the last argument).
Actuellement, le code généré utilise PyArg_ParseTuple()
, mais cela va bientôt changer.
How to use optional groups¶
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.
While functions using this approach can often be converted to
use PyArg_ParseTupleAndKeywords()
, optional arguments, and default values,
it's not always possible. Some of these legacy functions have
behaviors PyArg_ParseTupleAndKeywords()
doesn't directly support.
The most obvious example is the builtin function range()
, which has
an optional argument on the left side of its required argument!
Another example is curses.window.addch()
, which has a group of two
arguments that must always be specified together. (The arguments are
called x and y; if you call the function passing in x,
you must also pass in y — and if you don't pass in x you may not
pass in y either.)
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.
To specify an optional group, add a [
on a line by itself before
the parameters you wish to group together, and a ]
on a line by itself
after these parameters. As an example, here's how curses.window.addch()
uses optional groups to make the first two parameters and the last
parameter optional:
/*[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 soitright
ouleft
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 fonctionimpl
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.
How to use real Argument Clinic converters, instead of "legacy converters"¶
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
, ajouterNoneType
à 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 Cchar *
.- 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
etself
. 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 fonctionimpl
, juste après le paramètre chaîne, en tant que paramètre nommé<parameter_name>_length
.
Please note, not every possible combination of arguments will work.
Usually these arguments are implemented by specific PyArg_ParseTuple()
format units, with specific behavior. For example, currently you cannot
call unsigned_short
without also specifying bitwise=True
.
Although it's perfectly reasonable to think this would work, these semantics don't
map to any existing format unit. So Argument Clinic doesn't support it. (Or, at
least, not yet.)
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
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.
How to use the Py_buffer
converter¶
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).
How to use advanced converters¶
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.
The trick is, all those format units take arguments—either
conversion functions, or types, or strings specifying an encoding.
(But "legacy converters" don't support arguments. That's why we
skipped them for your first function.) The argument you specified
to the format unit is now an argument to the converter; this
argument is either converter (for O&
), subclass_of (for O!
),
or encoding (for all the format units that start with e
).
When using subclass_of, you may also want to use the other
custom argument for object()
: type, which lets you set the type
actually used for the parameter. For example, if you want to ensure
that the object is a subclass of PyUnicode_Type
, you probably want
to use the converter object(type='PyUnicodeObject *', subclass_of='&PyUnicode_Type')
.
One possible problem with using Argument Clinic: it takes away some possible
flexibility for the format units starting with e
. When writing a
PyArg_Parse*()
call by hand, you could theoretically decide at runtime what
encoding string to pass to that call. But now this string must
be hard-coded at Argument-Clinic-preprocessing-time. This limitation is deliberate;
it made supporting this format unit much easier, and may allow for future optimizations.
This restriction doesn't seem unreasonable; CPython itself always passes in static
hard-coded encoding strings for parameters whose format units start with e
.
How to assign default values to parameter¶
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
.
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
etNone
Simple symbolic constants like
sys.maxsize
, which must start with the name of the module
(Dans le futur, il est possible que l'on ait besoin de l'améliorer, pour autoriser les expressions complètes comme CONSTANT - 1
.)
Expressions as default values¶
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.
How to use return converters¶
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, using ->
notation.
For example:
/*[clinic input]
add -> int
a: int
b: int
/
[clinic start generated code]*/
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 (c:func: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
double
float
int
long
Py_ssize_t
size_t
unsigned int
unsigned long
None of these take parameters.
For all of these, return -1
to indicate 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.
How to clone 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.
How to call 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:...]*/
How to use the "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]*/
How to use the "defining class" converter¶
Argument Clinic facilitates gaining access to the defining class of a method.
This is useful for heap type methods that need to fetch
module level state. Use PyType_FromModuleAndSpec()
to associate a new
heap type with a module. You can now use PyType_GetModuleState()
on
the defining class to fetch the module state, for example from a module method.
Example from Modules/zlibmodule.c.
First, defining_class
is added to the clinic input:
/*[clinic input]
zlib.Compress.compress
cls: defining_class
data: Py_buffer
Binary data to be compressed.
/
After running the Argument Clinic tool, the following function signature is generated:
/*[clinic start generated code]*/
static PyObject *
zlib_Compress_compress_impl(compobject *self, PyTypeObject *cls,
Py_buffer *data)
/*[clinic end generated code: output=6731b3f0ff357ca6 input=04d00f65ab01d260]*/
The following code can now use PyType_GetModuleState(cls)
to fetch the
module state:
zlibstate *state = PyType_GetModuleState(cls);
Each method may only have one argument using this converter, and it must appear
after self
, or, if self
is not used, as the first argument. The argument
will be of type PyTypeObject *
. The argument will not appear in the
__text_signature__
.
The defining_class
converter is not compatible with __init__()
and __new__()
methods, which cannot use the METH_METHOD
convention.
It is not possible to use defining_class
with slot methods. In order to
fetch the module state from such methods, use PyType_GetModuleByDef()
to look up the module and then PyModule_GetState()
to fetch the module
state. Example from the setattro
slot method in
Modules/_threadmodule.c:
static int
local_setattro(localobject *self, PyObject *name, PyObject *v)
{
PyObject *module = PyType_GetModuleByDef(Py_TYPE(self), &thread_module);
thread_module_state *state = get_thread_state(module);
...
}
See also PEP 573.
How to write a custom converter¶
A converter is a Python class that inherits from CConverter
.
The main purpose of a custom converter, is for parameters parsed with
the O&
format unit --- parsing such a parameter means calling
a PyArg_ParseTuple()
"converter function".
Your converter class should be named ConverterName_converter
.
By following this convention, your converter class will be automatically
registered with Argument Clinic, with its converter name being the name of
your converter class with the _converter
suffix stripped off.
Instead of subclassing CConverter.__init__()
,
write a converter_init()
method.
converter_init()
always accepts a self parameter.
After self, all additional parameters must be keyword-only.
Any arguments passed to the converter in Argument Clinic
will be passed along to your converter_init()
method.
See CConverter
for a list of members you may wish to specify in
your subclass.
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 named ssize_t
to Argument Clinic.
Parameters declared as ssize_t
will be declared with type Py_ssize_t
,
and will be parsed by the 'O&'
format unit,
which will call the ssize_t_converter()
converter C 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
.
How to write 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.
How to convert METH_O
and METH_NOARGS
functions¶
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
.
How to convert 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 returnint
, notPyObject *
.Use the docstring as the class docstring.
Although
__new__
and__init__
functions must always accept both theargs
andkwargs
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.)
How to change and redirect 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 thePyMethodDef
structure is a field, calledmethoddef_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}
, wherebasename
andextension
were assigned the output fromos.path.splitext()
run on the current file. (Example: thefile
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
anddocstring_prototype
, write everything else toblock
.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 varioustypedef
andPyTypeObject
definitions.Suppress the
parser_prototype
anddocstring_prototype
, write theimpl_definition
toblock
, and write everything else tofile
.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 thanfile
, if your file has staticPyMethodDef
arrays defined in the middle of the file.Suppress the
parser_prototype
,impl_prototype
, anddocstring_prototype
, write theimpl_definition
toblock
, and write everything else tofile
.two-pass
Similar to the
buffer
preset, but writes forward declarations to thetwo-pass
buffer, and definitions to thebuffer
. This is similar to thebuffer
preset, but may require less editing thanbuffer
. Dump thetwo-pass
buffer near the top of your file, and dump thebuffer
near the end just like you would when using thebuffer
preset.Suppresses the
impl_prototype
, write theimpl_definition
toblock
, writedocstring_prototype
,methoddef_define
, andparser_prototype
totwo-pass
, write everything else tobuffer
.partial-buffer
Similar to the
buffer
preset, but writes more things toblock
, only writing the really big chunks of generated code tobuffer
. This avoids the definition-before-use problem ofbuffer
completely, at the small cost of having slightly more stuff in the block's output. Dump thebuffer
near the end, just like you would when using thebuffer
preset.Suppresses the
impl_prototype
, write thedocstring_definition
andparser_definition
tobuffer
, write everything else toblock
.
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.
How to use 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.
How to use 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:...]*/
How to override the generated signature¶
You can use the @text_signature
directive to override the default generated
signature in the docstring.
This can be useful for complex signatures that Argument Clinic cannot handle.
The @text_signature
directive takes one argument:
the custom signature as a string.
The provided signature is copied verbatim to the generated docstring.
Example from Objects/codeobject.c:
/*[clinic input]
@text_signature "($self, /, **changes)"
code.replace
*
co_argcount: int(c_default="self->co_argcount") = unchanged
co_posonlyargcount: int(c_default="self->co_posonlyargcount") = unchanged
# etc ...
Return a copy of the code object with new values for the specified fields.
[clinic start generated output]*/
The generated docstring ends up looking like this:
replace($self, /, **changes)
--
Return a copy of the code object with new values for the specified fields.