AFPy/python-docs-fr
AFPy/python-docs-fr
Fork 80
Code Issues 6 Pull requests 10 Activity

Make merge (#894)

Browse source
This commit is contained in:
Jules Lasne (jlasne) 2019-10-09 18:10:12 +02:00 • committed by GitHub
commit dcd871ae78
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
81 changed files with 10346 additions and 9121 deletions
Download patch file Download diff file Expand all files Collapse all files

256
extending/extending.po
View file

@ -5,7 +5,7 @@ msgid ""
msgstr ""
"Project-Id-Version: Python 3.6\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2019-05-23 16:48+0200\n"
"POT-Creation-Date: 2019-10-09 17:54+0200\n"
"PO-Revision-Date: 2019-06-19 21:54+0200\n"
"Last-Translator: Julien Palard <julien@palard.fr>\n"
"Language-Team: FRENCH <traductions@lists.afpy.org>\n"
@ -430,16 +430,16 @@ msgstr ""
"cela, déclarez simplement une variable statique au début de votre fichier ::"
#: ../Doc/extending/extending.rst:211
#, fuzzy
msgid ""
"and initialize it in your module's initialization function (:c:func:"
"`PyInit_spam`) with an exception object (leaving out the error checking for "
"now)::"
"`PyInit_spam`) with an exception object::"
msgstr ""
"et initialisez-la dans la fonction d'initialisation de votre module (:c:func:"
"`PyInit_spam`) avec un objet exception (Passons, pour le moment, la "
"vérification des codes d'erreur) ::"
#: ../Doc/extending/extending.rst:229
#: ../Doc/extending/extending.rst:235
msgid ""
"Note that the Python name for the exception object is :exc:`spam.error`. "
"The :c:func:`PyErr_NewException` function may create a class with the base "
@ -451,7 +451,7 @@ msgstr ""
"`Exception` (à moins qu'une autre classe ne lui soit fournie à la place de "
"*NULL*), voir :ref:`bltin-exceptions`."
#: ../Doc/extending/extending.rst:234
#: ../Doc/extending/extending.rst:240
msgid ""
"Note also that the :c:data:`SpamError` variable retains a reference to the "
"newly created exception class; this is intentional! Since the exception "
@ -469,7 +469,7 @@ msgstr ""
"défaillant, le C code qui lève l'exception peut engendrer un rejet central "
"ou des effets secondaires inattendus."
#: ../Doc/extending/extending.rst:241
#: ../Doc/extending/extending.rst:247
msgid ""
"We discuss the use of ``PyMODINIT_FUNC`` as a function return type later in "
"this sample."
@ -477,7 +477,7 @@ msgstr ""
"Nous traiterons de l'utilisation de ``PyMODINIT_FUNC`` comme un type de "
"retour de fonction plus tard dans cette section."
#: ../Doc/extending/extending.rst:244
#: ../Doc/extending/extending.rst:250
msgid ""
"The :exc:`spam.error` exception can be raised in your extension module using "
"a call to :c:func:`PyErr_SetString` as shown below::"
@ -485,11 +485,11 @@ msgstr ""
"L'exception :exc:`spam.error` peut être levée dans votre module d'extension "
"en appelant :c:func:`PyErr_SetString` comme montré ci-dessous ::"
#: ../Doc/extending/extending.rst:267
#: ../Doc/extending/extending.rst:273
msgid "Back to the Example"
msgstr "Retour vers l'exemple"
#: ../Doc/extending/extending.rst:269
#: ../Doc/extending/extending.rst:275
msgid ""
"Going back to our example function, you should now be able to understand "
"this statement::"
@ -497,7 +497,7 @@ msgstr ""
"En revenant vers notre fonction exemple, vous devriez maintenant être "
"capable de comprendre cette affirmation ::"
#: ../Doc/extending/extending.rst:275
#: ../Doc/extending/extending.rst:281
msgid ""
"It returns *NULL* (the error indicator for functions returning object "
"pointers) if an error is detected in the argument list, relying on the "
@ -516,7 +516,7 @@ msgstr ""
"la variable :c:data:`command` doit être clairement déclarée comme ``const "
"char *command``)."
#: ../Doc/extending/extending.rst:283
#: ../Doc/extending/extending.rst:289
msgid ""
"The next statement is a call to the Unix function :c:func:`system`, passing "
"it the string we just got from :c:func:`PyArg_ParseTuple`::"
@ -525,7 +525,7 @@ msgstr ""
"en lui passant la chaîne que nous venons d'obtenir à partir de :c:func:"
"`PyArg_ParseTuple` ::"
#: ../Doc/extending/extending.rst:288
#: ../Doc/extending/extending.rst:294
msgid ""
"Our :func:`spam.system` function must return the value of :c:data:`sts` as a "
"Python object. This is done using the function :c:func:`PyLong_FromLong`. ::"
@ -534,7 +534,7 @@ msgstr ""
"comme un objet Python. Cela est effectué par l'utilisation de la fonction :c:"
"func:`PyLong_FromLong`. ::"
#: ../Doc/extending/extending.rst:293
#: ../Doc/extending/extending.rst:299
msgid ""
"In this case, it will return an integer object. (Yes, even integers are "
"objects on the heap in Python!)"
@ -542,7 +542,7 @@ msgstr ""
"Dans ce cas, elle renverra un objet entier. (Oui, même les entiers sont des "
"objets dans le tas en Python!)"
#: ../Doc/extending/extending.rst:296
#: ../Doc/extending/extending.rst:302
msgid ""
"If you have a C function that returns no useful argument (a function "
"returning :c:type:`void`), the corresponding Python function must return "
@ -554,7 +554,7 @@ msgstr ""
"renvoyer ``None``. Vous aurez besoin de cette locution pour cela (qui est "
"implémentée par la macro :c:macro:`Py_RETURN_NONE`) ::"
#: ../Doc/extending/extending.rst:304
#: ../Doc/extending/extending.rst:310
msgid ""
":c:data:`Py_None` is the C name for the special Python object ``None``. It "
"is a genuine Python object rather than a *NULL* pointer, which means \"error"
@ -565,17 +565,17 @@ msgstr ""
"qu'une erreur est survenue, dans la plupart des situations, comme nous "
"l'avons vu."
#: ../Doc/extending/extending.rst:312
#: ../Doc/extending/extending.rst:318
msgid "The Module's Method Table and Initialization Function"
msgstr ""
#: ../Doc/extending/extending.rst:314
#: ../Doc/extending/extending.rst:320
msgid ""
"I promised to show how :c:func:`spam_system` is called from Python programs. "
"First, we need to list its name and address in a \"method table\"::"
msgstr ""
#: ../Doc/extending/extending.rst:325
#: ../Doc/extending/extending.rst:331
msgid ""
"Note the third entry (``METH_VARARGS``). This is a flag telling the "
"interpreter the calling convention to be used for the C function. It should "
@ -584,14 +584,14 @@ msgid ""
"is used."
msgstr ""
#: ../Doc/extending/extending.rst:330
#: ../Doc/extending/extending.rst:336
msgid ""
"When using only ``METH_VARARGS``, the function should expect the Python-"
"level parameters to be passed in as a tuple acceptable for parsing via :c:"
"func:`PyArg_ParseTuple`; more information on this function is provided below."
msgstr ""
#: ../Doc/extending/extending.rst:334
#: ../Doc/extending/extending.rst:340
msgid ""
"The :const:`METH_KEYWORDS` bit may be set in the third field if keyword "
"arguments should be passed to the function. In this case, the C function "
@ -600,12 +600,12 @@ msgid ""
"to such a function."
msgstr ""
#: ../Doc/extending/extending.rst:340
#: ../Doc/extending/extending.rst:346
msgid ""
"The method table must be referenced in the module definition structure::"
msgstr ""
#: ../Doc/extending/extending.rst:351
#: ../Doc/extending/extending.rst:357
msgid ""
"This structure, in turn, must be passed to the interpreter in the module's "
"initialization function. The initialization function must be named :c:func:"
@ -613,14 +613,14 @@ msgid ""
"only non-\\ ``static`` item defined in the module file::"
msgstr ""
#: ../Doc/extending/extending.rst:362
#: ../Doc/extending/extending.rst:368
msgid ""
"Note that PyMODINIT_FUNC declares the function as ``PyObject *`` return "
"type, declares any special linkage declarations required by the platform, "
"and for C++ declares the function as ``extern \"C\"``."
msgstr ""
#: ../Doc/extending/extending.rst:366
#: ../Doc/extending/extending.rst:372
msgid ""
"When the Python program imports module :mod:`spam` for the first time, :c:"
"func:`PyInit_spam` is called. (See below for comments about embedding "
@ -634,7 +634,7 @@ msgid ""
"gets inserted into ``sys.modules``."
msgstr ""
#: ../Doc/extending/extending.rst:377
#: ../Doc/extending/extending.rst:383
msgid ""
"When embedding Python, the :c:func:`PyInit_spam` function is not called "
"automatically unless there's an entry in the :c:data:`PyImport_Inittab` "
@ -642,7 +642,7 @@ msgid ""
"`PyImport_AppendInittab`, optionally followed by an import of the module::"
msgstr ""
#: ../Doc/extending/extending.rst:413
#: ../Doc/extending/extending.rst:419
msgid ""
"Removing entries from ``sys.modules`` or importing compiled modules into "
"multiple interpreters within a process (or following a :c:func:`fork` "
@ -651,14 +651,14 @@ msgid ""
"initializing internal data structures."
msgstr ""
#: ../Doc/extending/extending.rst:419
#: ../Doc/extending/extending.rst:425
msgid ""
"A more substantial example module is included in the Python source "
"distribution as :file:`Modules/xxmodule.c`. This file may be used as a "
"template or simply read as an example."
msgstr ""
#: ../Doc/extending/extending.rst:425
#: ../Doc/extending/extending.rst:431
msgid ""
"Unlike our ``spam`` example, ``xxmodule`` uses *multi-phase initialization* "
"(new in Python 3.5), where a PyModuleDef structure is returned from "
@ -666,11 +666,11 @@ msgid ""
"For details on multi-phase initialization, see :PEP:`489`."
msgstr ""
#: ../Doc/extending/extending.rst:434
#: ../Doc/extending/extending.rst:440
msgid "Compilation and Linkage"
msgstr ""
#: ../Doc/extending/extending.rst:436
#: ../Doc/extending/extending.rst:442
msgid ""
"There are two more things to do before you can use your new extension: "
"compiling and linking it with the Python system. If you use dynamic "
@ -680,7 +680,7 @@ msgid ""
"Windows (chapter :ref:`building-on-windows`) for more information about this."
msgstr ""
#: ../Doc/extending/extending.rst:443
#: ../Doc/extending/extending.rst:449
msgid ""
"If you can't use dynamic loading, or if you want to make your module a "
"permanent part of the Python interpreter, you will have to change the "
@ -690,7 +690,7 @@ msgid ""
"line to the file :file:`Modules/Setup.local` describing your file:"
msgstr ""
#: ../Doc/extending/extending.rst:454
#: ../Doc/extending/extending.rst:460
msgid ""
"and rebuild the interpreter by running :program:`make` in the toplevel "
"directory. You can also run :program:`make` in the :file:`Modules/` "
@ -699,17 +699,17 @@ msgid ""
"the :file:`Setup` file.)"
msgstr ""
#: ../Doc/extending/extending.rst:460
#: ../Doc/extending/extending.rst:466
msgid ""
"If your module requires additional libraries to link with, these can be "
"listed on the line in the configuration file as well, for instance:"
msgstr ""
#: ../Doc/extending/extending.rst:471
#: ../Doc/extending/extending.rst:477
msgid "Calling Python Functions from C"
msgstr ""
#: ../Doc/extending/extending.rst:473
#: ../Doc/extending/extending.rst:479
msgid ""
"So far we have concentrated on making C functions callable from Python. The "
"reverse is also useful: calling Python functions from C. This is especially "
@ -720,7 +720,7 @@ msgid ""
"uses are also imaginable."
msgstr ""
#: ../Doc/extending/extending.rst:481
#: ../Doc/extending/extending.rst:487
msgid ""
"Fortunately, the Python interpreter is easily called recursively, and there "
"is a standard interface to call a Python function. (I won't dwell on how to "
@ -729,7 +729,7 @@ msgid ""
"line option in :file:`Modules/main.c` from the Python source code.)"
msgstr ""
#: ../Doc/extending/extending.rst:487
#: ../Doc/extending/extending.rst:493
msgid ""
"Calling a Python function is easy. First, the Python program must somehow "
"pass you the Python function object. You should provide a function (or some "
@ -739,7 +739,7 @@ msgid ""
"function might be part of a module definition::"
msgstr ""
#: ../Doc/extending/extending.rst:517
#: ../Doc/extending/extending.rst:523
msgid ""
"This function must be registered with the interpreter using the :const:"
"`METH_VARARGS` flag; this is described in section :ref:`methodtable`. The :"
@ -747,7 +747,7 @@ msgid ""
"section :ref:`parsetuple`."
msgstr ""
#: ../Doc/extending/extending.rst:522
#: ../Doc/extending/extending.rst:528
msgid ""
"The macros :c:func:`Py_XINCREF` and :c:func:`Py_XDECREF` increment/decrement "
"the reference count of an object and are safe in the presence of *NULL* "
@ -755,7 +755,7 @@ msgid ""
"info on them in section :ref:`refcounts`."
msgstr ""
#: ../Doc/extending/extending.rst:529
#: ../Doc/extending/extending.rst:535
msgid ""
"Later, when it is time to call the function, you call the C function :c:func:"
"`PyObject_CallObject`. This function has two arguments, both pointers to "
@ -767,7 +767,7 @@ msgid ""
"or more format codes between parentheses. For example::"
msgstr ""
#: ../Doc/extending/extending.rst:549
#: ../Doc/extending/extending.rst:555
msgid ""
":c:func:`PyObject_CallObject` returns a Python object pointer: this is the "
"return value of the Python function. :c:func:`PyObject_CallObject` is "
@ -776,7 +776,7 @@ msgid ""
"`Py_DECREF`\\ -ed immediately after the :c:func:`PyObject_CallObject` call."
msgstr ""
#: ../Doc/extending/extending.rst:556
#: ../Doc/extending/extending.rst:562
msgid ""
"The return value of :c:func:`PyObject_CallObject` is \"new\": either it is a "
"brand new object, or it is an existing object whose reference count has been "
@ -785,7 +785,7 @@ msgid ""
"not interested in its value."
msgstr ""
#: ../Doc/extending/extending.rst:562
#: ../Doc/extending/extending.rst:568
msgid ""
"Before you do this, however, it is important to check that the return value "
"isn't *NULL*. If it is, the Python function terminated by raising an "
@ -796,7 +796,7 @@ msgid ""
"should be cleared by calling :c:func:`PyErr_Clear`. For example::"
msgstr ""
#: ../Doc/extending/extending.rst:575
#: ../Doc/extending/extending.rst:581
msgid ""
"Depending on the desired interface to the Python callback function, you may "
"also have to provide an argument list to :c:func:`PyObject_CallObject`. In "
@ -808,7 +808,7 @@ msgid ""
"you want to pass an integral event code, you might use the following code::"
msgstr ""
#: ../Doc/extending/extending.rst:594
#: ../Doc/extending/extending.rst:600
msgid ""
"Note the placement of ``Py_DECREF(arglist)`` immediately after the call, "
"before the error check! Also note that strictly speaking this code is not "
@ -816,22 +816,22 @@ msgid ""
"checked."
msgstr ""
#: ../Doc/extending/extending.rst:598
#: ../Doc/extending/extending.rst:604
msgid ""
"You may also call a function with keyword arguments by using :c:func:"
"`PyObject_Call`, which supports arguments and keyword arguments. As in the "
"above example, we use :c:func:`Py_BuildValue` to construct the dictionary. ::"
msgstr ""
#: ../Doc/extending/extending.rst:616
#: ../Doc/extending/extending.rst:622
msgid "Extracting Parameters in Extension Functions"
msgstr ""
#: ../Doc/extending/extending.rst:620
#: ../Doc/extending/extending.rst:626
msgid "The :c:func:`PyArg_ParseTuple` function is declared as follows::"
msgstr ""
#: ../Doc/extending/extending.rst:624
#: ../Doc/extending/extending.rst:630
msgid ""
"The *arg* argument must be a tuple object containing an argument list passed "
"from Python to a C function. The *format* argument must be a format string, "
@ -840,7 +840,7 @@ msgid ""
"whose type is determined by the format string."
msgstr ""
#: ../Doc/extending/extending.rst:630
#: ../Doc/extending/extending.rst:636
msgid ""
"Note that while :c:func:`PyArg_ParseTuple` checks that the Python arguments "
"have the required types, it cannot check the validity of the addresses of C "
@ -848,7 +848,7 @@ msgid ""
"probably crash or at least overwrite random bits in memory. So be careful!"
msgstr ""
#: ../Doc/extending/extending.rst:635
#: ../Doc/extending/extending.rst:641
msgid ""
"Note that any Python object references which are provided to the caller are "
"*borrowed* references; do not decrement their reference count!"
@ -857,20 +857,20 @@ msgstr ""
"à l'appelant sont des références *empruntées* ; ne décrémentez pas leur "
"compteur de références !"
#: ../Doc/extending/extending.rst:638
#: ../Doc/extending/extending.rst:644
msgid "Some example calls::"
msgstr ""
#: ../Doc/extending/extending.rst:708
#: ../Doc/extending/extending.rst:714
msgid "Keyword Parameters for Extension Functions"
msgstr ""
#: ../Doc/extending/extending.rst:712
#: ../Doc/extending/extending.rst:718
msgid ""
"The :c:func:`PyArg_ParseTupleAndKeywords` function is declared as follows::"
msgstr ""
#: ../Doc/extending/extending.rst:717
#: ../Doc/extending/extending.rst:723
msgid ""
"The *arg* and *format* parameters are identical to those of the :c:func:"
"`PyArg_ParseTuple` function. The *kwdict* parameter is the dictionary of "
@ -881,30 +881,30 @@ msgid ""
"returns true, otherwise it returns false and raises an appropriate exception."
msgstr ""
#: ../Doc/extending/extending.rst:727
#: ../Doc/extending/extending.rst:733
msgid ""
"Nested tuples cannot be parsed when using keyword arguments! Keyword "
"parameters passed in which are not present in the *kwlist* will cause :exc:"
"`TypeError` to be raised."
msgstr ""
#: ../Doc/extending/extending.rst:733
#: ../Doc/extending/extending.rst:739
msgid ""
"Here is an example module which uses keywords, based on an example by Geoff "
"Philbrick (philbrick@hks.com)::"
msgstr ""
#: ../Doc/extending/extending.rst:788
#: ../Doc/extending/extending.rst:794
msgid "Building Arbitrary Values"
msgstr ""
#: ../Doc/extending/extending.rst:790
#: ../Doc/extending/extending.rst:796
msgid ""
"This function is the counterpart to :c:func:`PyArg_ParseTuple`. It is "
"declared as follows::"
msgstr ""
#: ../Doc/extending/extending.rst:795
#: ../Doc/extending/extending.rst:801
msgid ""
"It recognizes a set of format units similar to the ones recognized by :c:"
"func:`PyArg_ParseTuple`, but the arguments (which are input to the function, "
@ -912,7 +912,7 @@ msgid ""
"object, suitable for returning from a C function called from Python."
msgstr ""
#: ../Doc/extending/extending.rst:800
#: ../Doc/extending/extending.rst:806
msgid ""
"One difference with :c:func:`PyArg_ParseTuple`: while the latter requires "
"its first argument to be a tuple (since Python argument lists are always "
@ -924,16 +924,16 @@ msgid ""
"parenthesize the format string."
msgstr ""
#: ../Doc/extending/extending.rst:808
#: ../Doc/extending/extending.rst:814
msgid ""
"Examples (to the left the call, to the right the resulting Python value):"
msgstr ""
#: ../Doc/extending/extending.rst:834
#: ../Doc/extending/extending.rst:840
msgid "Reference Counts"
msgstr ""
#: ../Doc/extending/extending.rst:836
#: ../Doc/extending/extending.rst:842
msgid ""
"In languages like C or C++, the programmer is responsible for dynamic "
"allocation and deallocation of memory on the heap. In C, this is done using "
@ -942,7 +942,7 @@ msgid ""
"restrict the following discussion to the C case."
msgstr ""
#: ../Doc/extending/extending.rst:842
#: ../Doc/extending/extending.rst:848
msgid ""
"Every block of memory allocated with :c:func:`malloc` should eventually be "
"returned to the pool of available memory by exactly one call to :c:func:"
@ -957,7 +957,7 @@ msgid ""
"crashes."
msgstr ""
#: ../Doc/extending/extending.rst:853
#: ../Doc/extending/extending.rst:859
msgid ""
"Common causes of memory leaks are unusual paths through the code. For "
"instance, a function may allocate a block of memory, do some calculation, "
@ -974,7 +974,7 @@ msgid ""
"of errors."
msgstr ""
#: ../Doc/extending/extending.rst:866
#: ../Doc/extending/extending.rst:872
msgid ""
"Since Python makes heavy use of :c:func:`malloc` and :c:func:`free`, it "
"needs a strategy to avoid memory leaks as well as the use of freed memory. "
@ -985,7 +985,7 @@ msgid ""
"reference to the object has been deleted and the object is freed."
msgstr ""
#: ../Doc/extending/extending.rst:874
#: ../Doc/extending/extending.rst:880
msgid ""
"An alternative strategy is called :dfn:`automatic garbage collection`. "
"(Sometimes, reference counting is also referred to as a garbage collection "
@ -1001,7 +1001,7 @@ msgid ""
"with reference counts."
msgstr ""
#: ../Doc/extending/extending.rst:886
#: ../Doc/extending/extending.rst:892
msgid ""
"While Python uses the traditional reference counting implementation, it also "
"offers a cycle detector that works to detect reference cycles. This allows "
@ -1015,7 +1015,7 @@ msgid ""
"though there are no further references to the cycle itself."
msgstr ""
#: ../Doc/extending/extending.rst:897
#: ../Doc/extending/extending.rst:903
msgid ""
"The cycle detector is able to detect garbage cycles and can reclaim them. "
"The :mod:`gc` module exposes a way to run the detector (the :func:`~gc."
@ -1027,11 +1027,11 @@ msgid ""
"detector is disabled in this way, the :mod:`gc` module will not be available."
msgstr ""
#: ../Doc/extending/extending.rst:911
#: ../Doc/extending/extending.rst:917
msgid "Reference Counting in Python"
msgstr ""
#: ../Doc/extending/extending.rst:913
#: ../Doc/extending/extending.rst:919
msgid ""
"There are two macros, ``Py_INCREF(x)`` and ``Py_DECREF(x)``, which handle "
"the incrementing and decrementing of the reference count. :c:func:"
@ -1042,7 +1042,7 @@ msgid ""
"object."
msgstr ""
#: ../Doc/extending/extending.rst:920
#: ../Doc/extending/extending.rst:926
msgid ""
"The big question now remains: when to use ``Py_INCREF(x)`` and "
"``Py_DECREF(x)``? Let's first introduce some terms. Nobody \"owns\" an "
@ -1055,7 +1055,7 @@ msgid ""
"reference creates a memory leak."
msgstr ""
#: ../Doc/extending/extending.rst:929
#: ../Doc/extending/extending.rst:935
msgid ""
"It is also possible to :dfn:`borrow` [#]_ a reference to an object. The "
"borrower of a reference should not call :c:func:`Py_DECREF`. The borrower "
@ -1064,7 +1064,7 @@ msgid ""
"risks using freed memory and should be avoided completely [#]_."
msgstr ""
#: ../Doc/extending/extending.rst:935
#: ../Doc/extending/extending.rst:941
msgid ""
"The advantage of borrowing over owning a reference is that you don't need to "
"take care of disposing of the reference on all possible paths through the "
@ -1075,7 +1075,7 @@ msgid ""
"borrowed has in fact disposed of it."
msgstr ""
#: ../Doc/extending/extending.rst:943
#: ../Doc/extending/extending.rst:949
msgid ""
"A borrowed reference can be changed into an owned reference by calling :c:"
"func:`Py_INCREF`. This does not affect the status of the owner from which "
@ -1084,18 +1084,18 @@ msgid ""
"properly, as well as the previous owner)."
msgstr ""
#: ../Doc/extending/extending.rst:953
#: ../Doc/extending/extending.rst:959
msgid "Ownership Rules"
msgstr ""
#: ../Doc/extending/extending.rst:955
#: ../Doc/extending/extending.rst:961
msgid ""
"Whenever an object reference is passed into or out of a function, it is part "
"of the function's interface specification whether ownership is transferred "
"with the reference or not."
msgstr ""
#: ../Doc/extending/extending.rst:959
#: ../Doc/extending/extending.rst:965
msgid ""
"Most functions that return a reference to an object pass on ownership with "
"the reference. In particular, all functions whose function it is to create "
@ -1106,7 +1106,7 @@ msgid ""
"reference to a cached item."
msgstr ""
#: ../Doc/extending/extending.rst:967
#: ../Doc/extending/extending.rst:973
msgid ""
"Many functions that extract objects from other objects also transfer "
"ownership with the reference, for instance :c:func:"
@ -1117,14 +1117,14 @@ msgid ""
"list or dictionary."
msgstr ""
#: ../Doc/extending/extending.rst:974
#: ../Doc/extending/extending.rst:980
msgid ""
"The function :c:func:`PyImport_AddModule` also returns a borrowed reference, "
"even though it may actually create the object it returns: this is possible "
"because an owned reference to the object is stored in ``sys.modules``."
msgstr ""
#: ../Doc/extending/extending.rst:978
#: ../Doc/extending/extending.rst:984
msgid ""
"When you pass an object reference into another function, in general, the "
"function borrows the reference from you --- if it needs to store it, it will "
@ -1135,7 +1135,7 @@ msgid ""
"don't take over ownership --- they are \"normal.\")"
msgstr ""
#: ../Doc/extending/extending.rst:986
#: ../Doc/extending/extending.rst:992
msgid ""
"When a C function is called from Python, it borrows references to its "
"arguments from the caller. The caller owns a reference to the object, so "
@ -1144,18 +1144,18 @@ msgid ""
"turned into an owned reference by calling :c:func:`Py_INCREF`."
msgstr ""
#: ../Doc/extending/extending.rst:992
#: ../Doc/extending/extending.rst:998
msgid ""
"The object reference returned from a C function that is called from Python "
"must be an owned reference --- ownership is transferred from the function to "
"its caller."
msgstr ""
#: ../Doc/extending/extending.rst:1000
#: ../Doc/extending/extending.rst:1006
msgid "Thin Ice"
msgstr ""
#: ../Doc/extending/extending.rst:1002
#: ../Doc/extending/extending.rst:1008
msgid ""
"There are a few situations where seemingly harmless use of a borrowed "
"reference can lead to problems. These all have to do with implicit "
@ -1163,21 +1163,21 @@ msgid ""
"dispose of it."
msgstr ""
#: ../Doc/extending/extending.rst:1006
#: ../Doc/extending/extending.rst:1012
msgid ""
"The first and most important case to know about is using :c:func:`Py_DECREF` "
"on an unrelated object while borrowing a reference to a list item. For "
"instance::"
msgstr ""
#: ../Doc/extending/extending.rst:1018
#: ../Doc/extending/extending.rst:1024
msgid ""
"This function first borrows a reference to ``list[0]``, then replaces "
"``list[1]`` with the value ``0``, and finally prints the borrowed reference. "
"Looks harmless, right? But it's not!"
msgstr ""
#: ../Doc/extending/extending.rst:1022
#: ../Doc/extending/extending.rst:1028
msgid ""
"Let's follow the control flow into :c:func:`PyList_SetItem`. The list owns "
"references to all its items, so when item 1 is replaced, it has to dispose "
@ -1187,7 +1187,7 @@ msgid ""
"count of 1, disposing of it will call its :meth:`__del__` method."
msgstr ""
#: ../Doc/extending/extending.rst:1029
#: ../Doc/extending/extending.rst:1035
msgid ""
"Since it is written in Python, the :meth:`__del__` method can execute "
"arbitrary Python code. Could it perhaps do something to invalidate the "
@ -1198,20 +1198,20 @@ msgid ""
"associated with it, thereby invalidating ``item``."
msgstr ""
#: ../Doc/extending/extending.rst:1037
#: ../Doc/extending/extending.rst:1043
msgid ""
"The solution, once you know the source of the problem, is easy: temporarily "
"increment the reference count. The correct version of the function reads::"
msgstr ""
#: ../Doc/extending/extending.rst:1051
#: ../Doc/extending/extending.rst:1057
msgid ""
"This is a true story. An older version of Python contained variants of this "
"bug and someone spent a considerable amount of time in a C debugger to "
"figure out why his :meth:`__del__` methods would fail..."
msgstr ""
#: ../Doc/extending/extending.rst:1055
#: ../Doc/extending/extending.rst:1061
msgid ""
"The second case of problems with a borrowed reference is a variant involving "
"threads. Normally, multiple threads in the Python interpreter can't get in "
@ -1224,11 +1224,11 @@ msgid ""
"previous one::"
msgstr ""
#: ../Doc/extending/extending.rst:1078
#: ../Doc/extending/extending.rst:1084
msgid "NULL Pointers"
msgstr ""
#: ../Doc/extending/extending.rst:1080
#: ../Doc/extending/extending.rst:1086
msgid ""
"In general, functions that take object references as arguments do not expect "
"you to pass them *NULL* pointers, and will dump core (or cause later core "
@ -1240,21 +1240,21 @@ msgid ""
"slowly."
msgstr ""
#: ../Doc/extending/extending.rst:1088
#: ../Doc/extending/extending.rst:1094
msgid ""
"It is better to test for *NULL* only at the \"source:\" when a pointer that "
"may be *NULL* is received, for example, from :c:func:`malloc` or from a "
"function that may raise an exception."
msgstr ""
#: ../Doc/extending/extending.rst:1092
#: ../Doc/extending/extending.rst:1098
msgid ""
"The macros :c:func:`Py_INCREF` and :c:func:`Py_DECREF` do not check for "
"*NULL* pointers --- however, their variants :c:func:`Py_XINCREF` and :c:func:"
"`Py_XDECREF` do."
msgstr ""
#: ../Doc/extending/extending.rst:1096
#: ../Doc/extending/extending.rst:1102
msgid ""
"The macros for checking for a particular object type (``Pytype_Check()``) "
"don't check for *NULL* pointers --- again, there is much code that calls "
@ -1263,24 +1263,24 @@ msgid ""
"variants with *NULL* checking."
msgstr ""
#: ../Doc/extending/extending.rst:1102
#: ../Doc/extending/extending.rst:1108
msgid ""
"The C function calling mechanism guarantees that the argument list passed to "
"C functions (``args`` in the examples) is never *NULL* --- in fact it "
"guarantees that it is always a tuple [#]_."
msgstr ""
#: ../Doc/extending/extending.rst:1106
#: ../Doc/extending/extending.rst:1112
msgid ""
"It is a severe error to ever let a *NULL* pointer \"escape\" to the Python "
"user."
msgstr ""
#: ../Doc/extending/extending.rst:1117
#: ../Doc/extending/extending.rst:1123
msgid "Writing Extensions in C++"
msgstr ""
#: ../Doc/extending/extending.rst:1119
#: ../Doc/extending/extending.rst:1125
msgid ""
"It is possible to write extension modules in C++. Some restrictions apply. "
"If the main program (the Python interpreter) is compiled and linked by the C "
@ -1293,11 +1293,11 @@ msgid ""
"(all recent C++ compilers define this symbol)."
msgstr ""
#: ../Doc/extending/extending.rst:1133
#: ../Doc/extending/extending.rst:1139
msgid "Providing a C API for an Extension Module"
msgstr ""
#: ../Doc/extending/extending.rst:1138
#: ../Doc/extending/extending.rst:1144
msgid ""
"Many extension modules just provide new functions and types to be used from "
"Python, but sometimes the code in an extension module can be useful for "
@ -1308,7 +1308,7 @@ msgid ""
"functions for direct manipulation from other extension modules."
msgstr ""
#: ../Doc/extending/extending.rst:1146
#: ../Doc/extending/extending.rst:1152
msgid ""
"At first sight this seems easy: just write the functions (without declaring "
"them ``static``, of course), provide an appropriate header file, and "
@ -1324,7 +1324,7 @@ msgid ""
"call might not have been loaded yet!"
msgstr ""
#: ../Doc/extending/extending.rst:1158
#: ../Doc/extending/extending.rst:1164
msgid ""
"Portability therefore requires not to make any assumptions about symbol "
"visibility. This means that all symbols in extension modules should be "
@ -1334,7 +1334,7 @@ msgid ""
"accessible from other extension modules must be exported in a different way."
msgstr ""
#: ../Doc/extending/extending.rst:1165
#: ../Doc/extending/extending.rst:1171
msgid ""
"Python provides a special mechanism to pass C-level information (pointers) "
"from one extension module to another one: Capsules. A Capsule is a Python "
@ -1346,7 +1346,7 @@ msgid ""
"the Capsule."
msgstr ""
#: ../Doc/extending/extending.rst:1173
#: ../Doc/extending/extending.rst:1179
msgid ""
"There are many ways in which Capsules can be used to export the C API of an "
"extension module. Each function could get its own Capsule, or all C API "
@ -1356,7 +1356,7 @@ msgid ""
"client modules."
msgstr ""
#: ../Doc/extending/extending.rst:1179
#: ../Doc/extending/extending.rst:1185
msgid ""
"Whichever method you choose, it's important to name your Capsules properly. "
"The function :c:func:`PyCapsule_New` takes a name parameter (:c:type:`const "
@ -1366,13 +1366,13 @@ msgid ""
"from another."
msgstr ""
#: ../Doc/extending/extending.rst:1186
#: ../Doc/extending/extending.rst:1192
msgid ""
"In particular, Capsules used to expose C APIs should be given a name "
"following this convention::"
msgstr ""
#: ../Doc/extending/extending.rst:1191
#: ../Doc/extending/extending.rst:1197
msgid ""
"The convenience function :c:func:`PyCapsule_Import` makes it easy to load a "
"C API provided via a Capsule, but only if the Capsule's name matches this "
@ -1380,7 +1380,7 @@ msgid ""
"the Capsule they load contains the correct C API."
msgstr ""
#: ../Doc/extending/extending.rst:1196
#: ../Doc/extending/extending.rst:1202
msgid ""
"The following example demonstrates an approach that puts most of the burden "
"on the writer of the exporting module, which is appropriate for commonly "
@ -1391,7 +1391,7 @@ msgid ""
"modules only have to call this macro before accessing the C API."
msgstr ""
#: ../Doc/extending/extending.rst:1204
#: ../Doc/extending/extending.rst:1210
msgid ""
"The exporting module is a modification of the :mod:`spam` module from "
"section :ref:`extending-simpleexample`. The function :func:`spam.system` "
@ -1401,25 +1401,25 @@ msgid ""
"function :c:func:`PySpam_System` is also exported to other extension modules."
msgstr ""
#: ../Doc/extending/extending.rst:1211
#: ../Doc/extending/extending.rst:1217
msgid ""
"The function :c:func:`PySpam_System` is a plain C function, declared "
"``static`` like everything else::"
msgstr ""
#: ../Doc/extending/extending.rst:1220
#: ../Doc/extending/extending.rst:1226
msgid "The function :c:func:`spam_system` is modified in a trivial way::"
msgstr ""
#: ../Doc/extending/extending.rst:1234
#: ../Doc/extending/extending.rst:1240
msgid "In the beginning of the module, right after the line ::"
msgstr ""
#: ../Doc/extending/extending.rst:1238
#: ../Doc/extending/extending.rst:1244
msgid "two more lines must be added::"
msgstr ""
#: ../Doc/extending/extending.rst:1243
#: ../Doc/extending/extending.rst:1249
msgid ""
"The ``#define`` is used to tell the header file that it is being included in "
"the exporting module, not a client module. Finally, the module's "
@ -1427,33 +1427,33 @@ msgid ""
"array::"
msgstr ""
#: ../Doc/extending/extending.rst:1269
#: ../Doc/extending/extending.rst:1279
msgid ""
"Note that ``PySpam_API`` is declared ``static``; otherwise the pointer array "
"would disappear when :func:`PyInit_spam` terminates!"
msgstr ""
#: ../Doc/extending/extending.rst:1272
#: ../Doc/extending/extending.rst:1282
msgid ""
"The bulk of the work is in the header file :file:`spammodule.h`, which looks "
"like this::"
msgstr ""
#: ../Doc/extending/extending.rst:1323
#: ../Doc/extending/extending.rst:1333
msgid ""
"All that a client module must do in order to have access to the function :c:"
"func:`PySpam_System` is to call the function (or rather macro) :c:func:"
"`import_spam` in its initialization function::"
msgstr ""
#: ../Doc/extending/extending.rst:1341
#: ../Doc/extending/extending.rst:1351
msgid ""
"The main disadvantage of this approach is that the file :file:`spammodule.h` "
"is rather complicated. However, the basic structure is the same for each "
"function that is exported, so it has to be learned only once."
msgstr ""
#: ../Doc/extending/extending.rst:1345
#: ../Doc/extending/extending.rst:1355
msgid ""
"Finally it should be mentioned that Capsules offer additional functionality, "
"which is especially useful for memory allocation and deallocation of the "
@ -1463,30 +1463,30 @@ msgid ""
"in the Python source code distribution)."
msgstr ""
#: ../Doc/extending/extending.rst:1353
#: ../Doc/extending/extending.rst:1363
msgid "Footnotes"
msgstr "Notes"
#: ../Doc/extending/extending.rst:1354
#: ../Doc/extending/extending.rst:1364
msgid ""
"An interface for this function already exists in the standard module :mod:"
"`os` --- it was chosen as a simple and straightforward example."
msgstr ""
#: ../Doc/extending/extending.rst:1357
#: ../Doc/extending/extending.rst:1367
msgid ""
"The metaphor of \"borrowing\" a reference is not completely correct: the "
"owner still has a copy of the reference."
msgstr ""
#: ../Doc/extending/extending.rst:1360
#: ../Doc/extending/extending.rst:1370
msgid ""
"Checking that the reference count is at least 1 **does not work** --- the "
"reference count itself could be in freed memory and may thus be reused for "
"another object!"
msgstr ""
#: ../Doc/extending/extending.rst:1364
#: ../Doc/extending/extending.rst:1374
msgid ""
"These guarantees don't hold when you use the \"old\" style calling "
"convention --- this is still found in much existing code."

188
extending/newtypes_tutorial.po
View file

@ -5,7 +5,7 @@ msgid ""
msgstr ""
"Project-Id-Version: Python 3.6\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2019-05-23 16:48+0200\n"
"POT-Creation-Date: 2019-10-09 17:54+0200\n"
"PO-Revision-Date: 2018-06-17 10:15+0200\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: FRENCH <traductions@lists.afpy.org>\n"
@ -219,40 +219,40 @@ msgid ""
"set to *NULL*. ::"
msgstr ""
#: ../Doc/extending/newtypes_tutorial.rst:184
#: ../Doc/extending/newtypes_tutorial.rst:189
msgid ""
"This adds the type to the module dictionary. This allows us to create :"
"class:`Custom` instances by calling the :class:`Custom` class:"
msgstr ""
#: ../Doc/extending/newtypes_tutorial.rst:192
#: ../Doc/extending/newtypes_tutorial.rst:197
msgid ""
"That's it! All that remains is to build it; put the above code in a file "
"called :file:`custom.c` and:"
msgstr ""
#: ../Doc/extending/newtypes_tutorial.rst:201
#: ../Doc/extending/newtypes_tutorial.rst:206
msgid "in a file called :file:`setup.py`; then typing"
msgstr ""
#: ../Doc/extending/newtypes_tutorial.rst:207
#: ../Doc/extending/newtypes_tutorial.rst:212
msgid ""
"at a shell should produce a file :file:`custom.so` in a subdirectory; move "
"to that directory and fire up Python --- you should be able to ``import "
"custom`` and play around with Custom objects."
msgstr ""
#: ../Doc/extending/newtypes_tutorial.rst:211
#: ../Doc/extending/newtypes_tutorial.rst:216
msgid "That wasn't so hard, was it?"
msgstr ""
#: ../Doc/extending/newtypes_tutorial.rst:213
#: ../Doc/extending/newtypes_tutorial.rst:218
msgid ""
"Of course, the current Custom type is pretty uninteresting. It has no data "
"and doesn't do anything. It can't even be subclassed."
msgstr ""
#: ../Doc/extending/newtypes_tutorial.rst:217
#: ../Doc/extending/newtypes_tutorial.rst:222
msgid ""
"While this documentation showcases the standard :mod:`distutils` module for "
"building C extensions, it is recommended in real-world use cases to use the "
@ -262,32 +262,32 @@ msgid ""
"packages/>`_."
msgstr ""
#: ../Doc/extending/newtypes_tutorial.rst:225
#: ../Doc/extending/newtypes_tutorial.rst:230
msgid "Adding data and methods to the Basic example"
msgstr ""
#: ../Doc/extending/newtypes_tutorial.rst:227
#: ../Doc/extending/newtypes_tutorial.rst:232
msgid ""
"Let's extend the basic example to add some data and methods. Let's also "
"make the type usable as a base class. We'll create a new module, :mod:"
"`custom2` that adds these capabilities:"
msgstr ""
#: ../Doc/extending/newtypes_tutorial.rst:234
#: ../Doc/extending/newtypes_tutorial.rst:239
msgid "This version of the module has a number of changes."
msgstr ""
#: ../Doc/extending/newtypes_tutorial.rst:236
#: ../Doc/extending/newtypes_tutorial.rst:241
msgid "We've added an extra include::"
msgstr ""
#: ../Doc/extending/newtypes_tutorial.rst:240
#: ../Doc/extending/newtypes_tutorial.rst:245
msgid ""
"This include provides declarations that we use to handle attributes, as "
"described a bit later."
msgstr ""
#: ../Doc/extending/newtypes_tutorial.rst:243
#: ../Doc/extending/newtypes_tutorial.rst:248
msgid ""
"The :class:`Custom` type now has three data attributes in its C struct, "
"*first*, *last*, and *number*. The *first* and *last* variables are Python "
@ -295,21 +295,21 @@ msgid ""
"integer."
msgstr ""
#: ../Doc/extending/newtypes_tutorial.rst:247
#: ../Doc/extending/newtypes_tutorial.rst:252
msgid "The object structure is updated accordingly::"
msgstr ""
#: ../Doc/extending/newtypes_tutorial.rst:256
#: ../Doc/extending/newtypes_tutorial.rst:261
msgid ""
"Because we now have data to manage, we have to be more careful about object "
"allocation and deallocation. At a minimum, we need a deallocation method::"
msgstr ""
#: ../Doc/extending/newtypes_tutorial.rst:267
#: ../Doc/extending/newtypes_tutorial.rst:272
msgid "which is assigned to the :c:member:`~PyTypeObject.tp_dealloc` member::"
msgstr ""
#: ../Doc/extending/newtypes_tutorial.rst:271
#: ../Doc/extending/newtypes_tutorial.rst:276
msgid ""
"This method first clears the reference counts of the two Python attributes. :"
"c:func:`Py_XDECREF` correctly handles the case where its argument is *NULL* "
@ -320,7 +320,7 @@ msgid ""
"subclass."
msgstr ""
#: ../Doc/extending/newtypes_tutorial.rst:280
#: ../Doc/extending/newtypes_tutorial.rst:285
msgid ""
"The explicit cast to ``destructor`` above is needed because we defined "
"``Custom_dealloc`` to take a ``CustomObject *`` argument, but the "
@ -329,17 +329,17 @@ msgid ""
"oriented polymorphism, in C!"
msgstr ""
#: ../Doc/extending/newtypes_tutorial.rst:286
#: ../Doc/extending/newtypes_tutorial.rst:291
msgid ""
"We want to make sure that the first and last names are initialized to empty "
"strings, so we provide a ``tp_new`` implementation::"
msgstr ""
#: ../Doc/extending/newtypes_tutorial.rst:310
#: ../Doc/extending/newtypes_tutorial.rst:315
msgid "and install it in the :c:member:`~PyTypeObject.tp_new` member::"
msgstr ""
#: ../Doc/extending/newtypes_tutorial.rst:314
#: ../Doc/extending/newtypes_tutorial.rst:319
msgid ""
"The ``tp_new`` handler is responsible for creating (as opposed to "
"initializing) objects of the type. It is exposed in Python as the :meth:"
@ -350,7 +350,7 @@ msgid ""
"attributes to non-*NULL* default values."
msgstr ""
#: ../Doc/extending/newtypes_tutorial.rst:322
#: ../Doc/extending/newtypes_tutorial.rst:327
msgid ""
"``tp_new`` is passed the type being instantiated (not necessarily "
"``CustomType``, if a subclass is instantiated) and any arguments passed when "
@ -360,25 +360,25 @@ msgid ""
"k.a. ``tp_init`` in C or ``__init__`` in Python) methods."
msgstr ""
#: ../Doc/extending/newtypes_tutorial.rst:330
#: ../Doc/extending/newtypes_tutorial.rst:335
msgid ""
"``tp_new`` shouldn't call ``tp_init`` explicitly, as the interpreter will do "
"it itself."
msgstr ""
#: ../Doc/extending/newtypes_tutorial.rst:333
#: ../Doc/extending/newtypes_tutorial.rst:338
msgid ""
"The ``tp_new`` implementation calls the :c:member:`~PyTypeObject.tp_alloc` "
"slot to allocate memory::"
msgstr ""
#: ../Doc/extending/newtypes_tutorial.rst:338
#: ../Doc/extending/newtypes_tutorial.rst:343
msgid ""
"Since memory allocation may fail, we must check the :c:member:`~PyTypeObject."
"tp_alloc` result against *NULL* before proceeding."
msgstr ""
#: ../Doc/extending/newtypes_tutorial.rst:342
#: ../Doc/extending/newtypes_tutorial.rst:347
msgid ""
"We didn't fill the :c:member:`~PyTypeObject.tp_alloc` slot ourselves. "
"Rather :c:func:`PyType_Ready` fills it for us by inheriting it from our base "
@ -386,7 +386,7 @@ msgid ""
"allocation strategy."
msgstr ""
#: ../Doc/extending/newtypes_tutorial.rst:348
#: ../Doc/extending/newtypes_tutorial.rst:353
msgid ""
"If you are creating a co-operative :c:member:`~PyTypeObject.tp_new` (one "
"that calls a base type's :c:member:`~PyTypeObject.tp_new` or :meth:"
@ -399,17 +399,17 @@ msgid ""
"subclasses without getting a :exc:`TypeError`.)"
msgstr ""
#: ../Doc/extending/newtypes_tutorial.rst:358
#: ../Doc/extending/newtypes_tutorial.rst:363
msgid ""
"We also define an initialization function which accepts arguments to provide "
"initial values for our instance::"
msgstr ""
#: ../Doc/extending/newtypes_tutorial.rst:387
#: ../Doc/extending/newtypes_tutorial.rst:392
msgid "by filling the :c:member:`~PyTypeObject.tp_init` slot. ::"
msgstr ""
#: ../Doc/extending/newtypes_tutorial.rst:391
#: ../Doc/extending/newtypes_tutorial.rst:396
msgid ""
"The :c:member:`~PyTypeObject.tp_init` slot is exposed in Python as the :meth:"
"`__init__` method. It is used to initialize an object after it's created. "
@ -417,7 +417,7 @@ msgid ""
"return either ``0`` on success or ``-1`` on error."
msgstr ""
#: ../Doc/extending/newtypes_tutorial.rst:396
#: ../Doc/extending/newtypes_tutorial.rst:401
msgid ""
"Unlike the ``tp_new`` handler, there is no guarantee that ``tp_init`` is "
"called at all (for example, the :mod:`pickle` module by default doesn't "
@ -428,7 +428,7 @@ msgid ""
"``first`` member like this::"
msgstr ""
#: ../Doc/extending/newtypes_tutorial.rst:410
#: ../Doc/extending/newtypes_tutorial.rst:415
msgid ""
"But this would be risky. Our type doesn't restrict the type of the "
"``first`` member, so it could be any kind of object. It could have a "
@ -438,49 +438,49 @@ msgid ""
"and modifies our object."
msgstr ""
#: ../Doc/extending/newtypes_tutorial.rst:417
#: ../Doc/extending/newtypes_tutorial.rst:422
msgid ""
"To be paranoid and protect ourselves against this possibility, we almost "
"always reassign members before decrementing their reference counts. When "
"don't we have to do this?"
msgstr ""
#: ../Doc/extending/newtypes_tutorial.rst:421
#: ../Doc/extending/newtypes_tutorial.rst:426
msgid "when we absolutely know that the reference count is greater than 1;"
msgstr ""
#: ../Doc/extending/newtypes_tutorial.rst:423
#: ../Doc/extending/newtypes_tutorial.rst:428
msgid ""
"when we know that deallocation of the object [#]_ will neither release the :"
"term:`GIL` nor cause any calls back into our type's code;"
msgstr ""
#: ../Doc/extending/newtypes_tutorial.rst:426
#: ../Doc/extending/newtypes_tutorial.rst:431
msgid ""
"when decrementing a reference count in a :c:member:`~PyTypeObject."
"tp_dealloc` handler on a type which doesn't support cyclic garbage "
"collection [#]_."
msgstr ""
#: ../Doc/extending/newtypes_tutorial.rst:429
#: ../Doc/extending/newtypes_tutorial.rst:434
msgid ""
"We want to expose our instance variables as attributes. There are a number "
"of ways to do that. The simplest way is to define member definitions::"
msgstr ""
#: ../Doc/extending/newtypes_tutorial.rst:442
#: ../Doc/extending/newtypes_tutorial.rst:447
msgid ""
"and put the definitions in the :c:member:`~PyTypeObject.tp_members` slot::"
msgstr ""
#: ../Doc/extending/newtypes_tutorial.rst:446
#: ../Doc/extending/newtypes_tutorial.rst:451
msgid ""
"Each member definition has a member name, type, offset, access flags and "
"documentation string. See the :ref:`Generic-Attribute-Management` section "
"below for details."
msgstr ""
#: ../Doc/extending/newtypes_tutorial.rst:450
#: ../Doc/extending/newtypes_tutorial.rst:455
msgid ""
"A disadvantage of this approach is that it doesn't provide a way to restrict "
"the types of objects that can be assigned to the Python attributes. We "
@ -491,13 +491,13 @@ msgid ""
"deleted."
msgstr ""
#: ../Doc/extending/newtypes_tutorial.rst:457
#: ../Doc/extending/newtypes_tutorial.rst:462
msgid ""
"We define a single method, :meth:`Custom.name()`, that outputs the objects "
"name as the concatenation of the first and last names. ::"
msgstr ""
#: ../Doc/extending/newtypes_tutorial.rst:474
#: ../Doc/extending/newtypes_tutorial.rst:479
msgid ""
"The method is implemented as a C function that takes a :class:`Custom` (or :"
"class:`Custom` subclass) instance as the first argument. Methods always "
@ -507,7 +507,7 @@ msgid ""
"method is equivalent to the Python method:"
msgstr ""
#: ../Doc/extending/newtypes_tutorial.rst:486
#: ../Doc/extending/newtypes_tutorial.rst:491
msgid ""
"Note that we have to check for the possibility that our :attr:`first` and :"
"attr:`last` members are *NULL*. This is because they can be deleted, in "
@ -516,23 +516,23 @@ msgid ""
"We'll see how to do that in the next section."
msgstr ""
#: ../Doc/extending/newtypes_tutorial.rst:492
#: ../Doc/extending/newtypes_tutorial.rst:497
msgid ""
"Now that we've defined the method, we need to create an array of method "
"definitions::"
msgstr ""
#: ../Doc/extending/newtypes_tutorial.rst:502
#: ../Doc/extending/newtypes_tutorial.rst:507
msgid ""
"(note that we used the :const:`METH_NOARGS` flag to indicate that the method "
"is expecting no arguments other than *self*)"
msgstr ""
#: ../Doc/extending/newtypes_tutorial.rst:505
#: ../Doc/extending/newtypes_tutorial.rst:510
msgid "and assign it to the :c:member:`~PyTypeObject.tp_methods` slot::"
msgstr ""
#: ../Doc/extending/newtypes_tutorial.rst:509
#: ../Doc/extending/newtypes_tutorial.rst:514
msgid ""
"Finally, we'll make our type usable as a base class for subclassing. We've "
"written our methods carefully so far so that they don't make any assumptions "
@ -540,22 +540,22 @@ msgid ""
"to add the :const:`Py_TPFLAGS_BASETYPE` to our class flag definition::"
msgstr ""
#: ../Doc/extending/newtypes_tutorial.rst:516
#: ../Doc/extending/newtypes_tutorial.rst:521
msgid ""
"We rename :c:func:`PyInit_custom` to :c:func:`PyInit_custom2`, update the "
"module name in the :c:type:`PyModuleDef` struct, and update the full class "
"name in the :c:type:`PyTypeObject` struct."
msgstr ""
#: ../Doc/extending/newtypes_tutorial.rst:520
#: ../Doc/extending/newtypes_tutorial.rst:525
msgid "Finally, we update our :file:`setup.py` file to build the new module:"
msgstr ""
#: ../Doc/extending/newtypes_tutorial.rst:533
#: ../Doc/extending/newtypes_tutorial.rst:538
msgid "Providing finer control over data attributes"
msgstr ""
#: ../Doc/extending/newtypes_tutorial.rst:535
#: ../Doc/extending/newtypes_tutorial.rst:540
msgid ""
"In this section, we'll provide finer control over how the :attr:`first` and :"
"attr:`last` attributes are set in the :class:`Custom` example. In the "
@ -564,14 +564,14 @@ msgid ""
"make sure that these attributes always contain strings."
msgstr ""
#: ../Doc/extending/newtypes_tutorial.rst:544
#: ../Doc/extending/newtypes_tutorial.rst:549
msgid ""
"To provide greater control, over the :attr:`first` and :attr:`last` "
"attributes, we'll use custom getter and setter functions. Here are the "
"functions for getting and setting the :attr:`first` attribute::"
msgstr ""
#: ../Doc/extending/newtypes_tutorial.rst:575
#: ../Doc/extending/newtypes_tutorial.rst:580
msgid ""
"The getter function is passed a :class:`Custom` object and a \"closure\", "
"which is a void pointer. In this case, the closure is ignored. (The "
@ -581,7 +581,7 @@ msgid ""
"data in the closure.)"
msgstr ""
#: ../Doc/extending/newtypes_tutorial.rst:581
#: ../Doc/extending/newtypes_tutorial.rst:586
msgid ""
"The setter function is passed the :class:`Custom` object, the new value, and "
"the closure. The new value may be *NULL*, in which case the attribute is "
@ -589,32 +589,32 @@ msgid ""
"or if its new value is not a string."
msgstr ""
#: ../Doc/extending/newtypes_tutorial.rst:586
#: ../Doc/extending/newtypes_tutorial.rst:591
msgid "We create an array of :c:type:`PyGetSetDef` structures::"
msgstr ""
#: ../Doc/extending/newtypes_tutorial.rst:596
#: ../Doc/extending/newtypes_tutorial.rst:601
msgid "and register it in the :c:member:`~PyTypeObject.tp_getset` slot::"
msgstr ""
#: ../Doc/extending/newtypes_tutorial.rst:600
#: ../Doc/extending/newtypes_tutorial.rst:605
msgid ""
"The last item in a :c:type:`PyGetSetDef` structure is the \"closure\" "
"mentioned above. In this case, we aren't using a closure, so we just pass "
"*NULL*."
msgstr ""
#: ../Doc/extending/newtypes_tutorial.rst:603
#: ../Doc/extending/newtypes_tutorial.rst:608
msgid "We also remove the member definitions for these attributes::"
msgstr ""
#: ../Doc/extending/newtypes_tutorial.rst:611
#: ../Doc/extending/newtypes_tutorial.rst:616
msgid ""
"We also need to update the :c:member:`~PyTypeObject.tp_init` handler to only "
"allow strings [#]_ to be passed::"
msgstr ""
#: ../Doc/extending/newtypes_tutorial.rst:640
#: ../Doc/extending/newtypes_tutorial.rst:645
msgid ""
"With these changes, we can assure that the ``first`` and ``last`` members "
"are never *NULL* so we can remove checks for *NULL* values in almost all "
@ -624,25 +624,25 @@ msgid ""
"possibility that the initialization of these members failed in ``tp_new``."
msgstr ""
#: ../Doc/extending/newtypes_tutorial.rst:647
#: ../Doc/extending/newtypes_tutorial.rst:652
msgid ""
"We also rename the module initialization function and module name in the "
"initialization function, as we did before, and we add an extra definition to "
"the :file:`setup.py` file."
msgstr ""
#: ../Doc/extending/newtypes_tutorial.rst:653
#: ../Doc/extending/newtypes_tutorial.rst:658
msgid "Supporting cyclic garbage collection"
msgstr ""
#: ../Doc/extending/newtypes_tutorial.rst:655
#: ../Doc/extending/newtypes_tutorial.rst:660
msgid ""
"Python has a :term:`cyclic garbage collector (GC) <garbage collection>` that "
"can identify unneeded objects even when their reference counts are not zero. "
"This can happen when objects are involved in cycles. For example, consider:"
msgstr ""
#: ../Doc/extending/newtypes_tutorial.rst:665
#: ../Doc/extending/newtypes_tutorial.rst:670
msgid ""
"In this example, we create a list that contains itself. When we delete it, "
"it still has a reference from itself. Its reference count doesn't drop to "
@ -650,7 +650,7 @@ msgid ""
"out that the list is garbage and free it."
msgstr ""
#: ../Doc/extending/newtypes_tutorial.rst:670
#: ../Doc/extending/newtypes_tutorial.rst:675
msgid ""
"In the second version of the :class:`Custom` example, we allowed any kind of "
"object to be stored in the :attr:`first` or :attr:`last` attributes [#]_. "
@ -659,7 +659,7 @@ msgid ""
"reasons, :class:`Custom` objects can participate in cycles:"
msgstr ""
#: ../Doc/extending/newtypes_tutorial.rst:684
#: ../Doc/extending/newtypes_tutorial.rst:689
msgid ""
"To allow a :class:`Custom` instance participating in a reference cycle to be "
"properly detected and collected by the cyclic GC, our :class:`Custom` type "
@ -667,13 +667,13 @@ msgid ""
"slots:"
msgstr ""
#: ../Doc/extending/newtypes_tutorial.rst:691
#: ../Doc/extending/newtypes_tutorial.rst:696
msgid ""
"First, the traversal method lets the cyclic GC know about subobjects that "
"could participate in cycles::"
msgstr ""
#: ../Doc/extending/newtypes_tutorial.rst:711
#: ../Doc/extending/newtypes_tutorial.rst:716
msgid ""
"For each subobject that can participate in cycles, we need to call the :c:"
"func:`visit` function, which is passed to the traversal method. The :c:func:"
@ -682,26 +682,26 @@ msgid ""
"be returned if it is non-zero."
msgstr ""
#: ../Doc/extending/newtypes_tutorial.rst:717
#: ../Doc/extending/newtypes_tutorial.rst:722
msgid ""
"Python provides a :c:func:`Py_VISIT` macro that automates calling visit "
"functions. With :c:func:`Py_VISIT`, we can minimize the amount of "
"boilerplate in ``Custom_traverse``::"
msgstr ""
#: ../Doc/extending/newtypes_tutorial.rst:730
#: ../Doc/extending/newtypes_tutorial.rst:735
msgid ""
"The :c:member:`~PyTypeObject.tp_traverse` implementation must name its "
"arguments exactly *visit* and *arg* in order to use :c:func:`Py_VISIT`."
msgstr ""
#: ../Doc/extending/newtypes_tutorial.rst:733
#: ../Doc/extending/newtypes_tutorial.rst:738
msgid ""
"Second, we need to provide a method for clearing any subobjects that can "
"participate in cycles::"
msgstr ""
#: ../Doc/extending/newtypes_tutorial.rst:744
#: ../Doc/extending/newtypes_tutorial.rst:749
msgid ""
"Notice the use of the :c:func:`Py_CLEAR` macro. It is the recommended and "
"safe way to clear data attributes of arbitrary types while decrementing "
@ -711,18 +711,18 @@ msgid ""
"again (*especially* if there is a reference cycle)."
msgstr ""
#: ../Doc/extending/newtypes_tutorial.rst:752
#: ../Doc/extending/newtypes_tutorial.rst:757
msgid "You could emulate :c:func:`Py_CLEAR` by writing::"
msgstr ""
#: ../Doc/extending/newtypes_tutorial.rst:759
#: ../Doc/extending/newtypes_tutorial.rst:764
msgid ""
"Nevertheless, it is much easier and less error-prone to always use :c:func:"
"`Py_CLEAR` when deleting an attribute. Don't try to micro-optimize at the "
"expense of robustness!"
msgstr ""
#: ../Doc/extending/newtypes_tutorial.rst:763
#: ../Doc/extending/newtypes_tutorial.rst:768
msgid ""
"The deallocator ``Custom_dealloc`` may call arbitrary code when clearing "
"attributes. It means the circular GC can be triggered inside the function. "
@ -732,12 +732,12 @@ msgid ""
"`PyObject_GC_UnTrack` and ``Custom_clear``::"
msgstr ""
#: ../Doc/extending/newtypes_tutorial.rst:778
#: ../Doc/extending/newtypes_tutorial.rst:783
msgid ""
"Finally, we add the :const:`Py_TPFLAGS_HAVE_GC` flag to the class flags::"
msgstr ""
#: ../Doc/extending/newtypes_tutorial.rst:782
#: ../Doc/extending/newtypes_tutorial.rst:787
msgid ""
"That's pretty much it. If we had written custom :c:member:`~PyTypeObject."
"tp_alloc` or :c:member:`~PyTypeObject.tp_free` handlers, we'd need to modify "
@ -745,11 +745,11 @@ msgid ""
"automatically provided."
msgstr ""
#: ../Doc/extending/newtypes_tutorial.rst:788
#: ../Doc/extending/newtypes_tutorial.rst:793
msgid "Subclassing other types"
msgstr ""
#: ../Doc/extending/newtypes_tutorial.rst:790
#: ../Doc/extending/newtypes_tutorial.rst:795
msgid ""
"It is possible to create new extension types that are derived from existing "
"types. It is easiest to inherit from the built in types, since an extension "
@ -757,7 +757,7 @@ msgid ""
"share these :c:type:`PyTypeObject` structures between extension modules."
msgstr ""
#: ../Doc/extending/newtypes_tutorial.rst:795
#: ../Doc/extending/newtypes_tutorial.rst:800
msgid ""
"In this example we will create a :class:`SubList` type that inherits from "
"the built-in :class:`list` type. The new type will be completely compatible "
@ -765,34 +765,34 @@ msgid ""
"that increases an internal counter:"
msgstr ""
#: ../Doc/extending/newtypes_tutorial.rst:815
#: ../Doc/extending/newtypes_tutorial.rst:820
msgid ""
"As you can see, the source code closely resembles the :class:`Custom` "
"examples in previous sections. We will break down the main differences "
"between them. ::"
msgstr ""
#: ../Doc/extending/newtypes_tutorial.rst:823
#: ../Doc/extending/newtypes_tutorial.rst:828
msgid ""
"The primary difference for derived type objects is that the base type's "
"object structure must be the first value. The base type will already "
"include the :c:func:`PyObject_HEAD` at the beginning of its structure."
msgstr ""
#: ../Doc/extending/newtypes_tutorial.rst:827
#: ../Doc/extending/newtypes_tutorial.rst:832
msgid ""
"When a Python object is a :class:`SubList` instance, its ``PyObject *`` "
"pointer can be safely cast to both ``PyListObject *`` and ``SubListObject "
"*``::"
msgstr ""
#: ../Doc/extending/newtypes_tutorial.rst:839
#: ../Doc/extending/newtypes_tutorial.rst:844
msgid ""
"We see above how to call through to the :attr:`__init__` method of the base "
"type."
msgstr ""
#: ../Doc/extending/newtypes_tutorial.rst:842
#: ../Doc/extending/newtypes_tutorial.rst:847
msgid ""
"This pattern is important when writing a type with custom :c:member:"
"`~PyTypeObject.tp_new` and :c:member:`~PyTypeObject.tp_dealloc` members. "
@ -801,7 +801,7 @@ msgid ""
"the base class handle it by calling its own :c:member:`~PyTypeObject.tp_new`."
msgstr ""
#: ../Doc/extending/newtypes_tutorial.rst:848
#: ../Doc/extending/newtypes_tutorial.rst:853
msgid ""
"The :c:type:`PyTypeObject` struct supports a :c:member:`~PyTypeObject."
"tp_base` specifying the type's concrete base class. Due to cross-platform "
@ -810,7 +810,7 @@ msgid ""
"function::"
msgstr ""
#: ../Doc/extending/newtypes_tutorial.rst:871
#: ../Doc/extending/newtypes_tutorial.rst:881
msgid ""
"Before calling :c:func:`PyType_Ready`, the type structure must have the :c:"
"member:`~PyTypeObject.tp_base` slot filled in. When we are deriving an "
@ -819,29 +819,29 @@ msgid ""
"from the base type will be inherited."
msgstr ""
#: ../Doc/extending/newtypes_tutorial.rst:877
#: ../Doc/extending/newtypes_tutorial.rst:887
msgid ""
"After that, calling :c:func:`PyType_Ready` and adding the type object to the "
"module is the same as with the basic :class:`Custom` examples."
msgstr ""
#: ../Doc/extending/newtypes_tutorial.rst:882
#: ../Doc/extending/newtypes_tutorial.rst:892
msgid "Footnotes"
msgstr "Notes"
#: ../Doc/extending/newtypes_tutorial.rst:883
#: ../Doc/extending/newtypes_tutorial.rst:893
msgid ""
"This is true when we know that the object is a basic type, like a string or "
"a float."
msgstr ""
#: ../Doc/extending/newtypes_tutorial.rst:886
#: ../Doc/extending/newtypes_tutorial.rst:896
msgid ""
"We relied on this in the :c:member:`~PyTypeObject.tp_dealloc` handler in "
"this example, because our type doesn't support garbage collection."
msgstr ""
#: ../Doc/extending/newtypes_tutorial.rst:889
#: ../Doc/extending/newtypes_tutorial.rst:899
msgid ""
"We now know that the first and last members are strings, so perhaps we could "
"be less careful about decrementing their reference counts, however, we "
@ -851,7 +851,7 @@ msgid ""
"objects."
msgstr ""
#: ../Doc/extending/newtypes_tutorial.rst:895
#: ../Doc/extending/newtypes_tutorial.rst:905
msgid ""
"Also, even with our attributes restricted to strings instances, the user "
"could pass arbitrary :class:`str` subclasses and therefore still create "