Update extending.po

Après relecture de votre travail et quelques corrections mineures, j'ai brièvement continué là où vous vous êtes arrétés.

extending.po

@@ -987,12 +987,12 @@ msgid ""
 "code and tries to find an exception handler specified by the Python "
 "programmer."
 msgstr ""
-"lorsqu'une fonction *f* ayant appelé une autre fonction *g* détecte que "
+"Lorsqu'une fonction *f* ayant appelé une autre fonction *g* détecte que "
 "cette dernière a échoué, *f* devrait donner une valeur d'erreur à son tour "
 "(habituellement *NULL* ou ``-1``). *f* ne devrait *pas* appeler l'une des "
 "fonctions :c:func:`PyErr_\\*`, l'une d'elles ayant déjà été appelée par *g*. "
 "La fonction appelant *f* est alors censée retourner aussi un code d'erreur à "
-"celle qui la appelée, toujours sans utiliser :c:func:`PyErr_\\*`, et ainsi "
+"celle qui l'a appelée, toujours sans utiliser :c:func:`PyErr_\\*`, et ainsi "
 "de suite. La cause la plus détaillée de l'erreur a déjà été signalée par la "
 "fonction l'ayant détectée en premier. Une fois l'erreur remontée à la boucle "
 "principale de l'interpréteur Python, il interrompt le code en cours "
@@ -1009,7 +1009,7 @@ msgid ""
 msgstr ""
 "(Il ya des situations où un module peut effectivement donner un message "
 "d'erreur plus détaillé en appelant une autre fonction :c:func:`PyErr_\\*`, "
-"dans de tels cas, c'est tout à fait possible de le faire. Cependant, ce "
+"dans de tels cas, il est tout à fait possible de le faire. Cependant, ce "
 "n'est généralement pas nécessaire, et peut amener à perdre des informations "
 "sur la cause de l'erreur: la plupart des opérations peuvent échouer pour "
 "tout un tas de raisons)."
@@ -1022,12 +1022,12 @@ msgid ""
 "pass the error on to the interpreter but wants to handle it completely by "
 "itself (possibly by trying something else, or pretending nothing went wrong)."
 msgstr ""
-"Pour ignorer une exception qui aurait été émise lors d'un un appel de "
+"Pour ignorer une exception qui aurait été émise lors d'un appel de "
 "fonction qui aurait échoué, l'exception doit être retirée explicitement en "
 "appelant :c:func:`PyErr_Clear`. Le seul cas pour lequel du code C devrait "
 "appeler :c:func:`PyErr_Clear` est lorsqu'il ne veut pas passer l'erreur à "
 "l'interpréteur, mais souhaite la gérer lui-même (peut-être en essayant "
-"quelque chose d'autre, ou de prétendre rien a mal tourné)."
+"quelque chose d'autre, ou en prétendant que rien n'a mal tourné)."
 
 #: extending/extending.rst:175
 msgid ""
@@ -1054,7 +1054,7 @@ msgstr ""
 "Notez également que, à l'exception notable de :c:func:`PyArg_ParseTuple` et "
 "compagnie, les fonctions qui renvoient leur statut sous forme d'entier "
 "donnent généralement une valeur positive ou zéro en cas de succès et ``-1`` "
-"en cas d'échec, comme les appels système Unix."
+"en cas d'échec, comme les appels du système Unix."
 
 #: extending/extending.rst:185
 msgid ""
@@ -1064,7 +1064,7 @@ msgid ""
 msgstr ""
 "Enfin, lorsque vous renvoyez un code d'erreur, n'oubliez pas faire un brin "
 "de nettoyage (en appelant :c:func:`Py_XDECREF` ou :c: func:` Py_DECREF` avec "
-"les objets que vous auriez déjà créé)  !"
+"les objets que vous auriez déjà créés)  !"
 
 #: extending/extending.rst:189
 msgid ""
@@ -1084,9 +1084,9 @@ msgstr ""
 "judicieusement vos exceptions, typiquement n'utilisez pas :c:data:"
 "`PyExc_TypeError` pour indiquer qu'un fichier n'a pas pu être ouvert (qui "
 "devrait probablement être :c:data:`PyExc_IOError`). Si quelque chose ne va "
-"pas avec la liste d'arguments, la fonction :c:func:`PyArg_ParseTuple` "
+"pas avec la liste des arguments, la fonction :c:func:`PyArg_ParseTuple` "
 "soulève habituellement une exception :c:data:`PyExc_TypeError`. Mais si vous "
-"avez un argument dont la valeur doit être dans une intervalle particulière "
+"avez un argument dont la valeur doit être dans un intervalle particulier "
 "ou qui doit satisfaire d'autres conditions, :c:data:`PyExc_ValueError` sera "
 "plus appropriée."
 
@@ -1130,28 +1130,40 @@ msgid ""
 "pointer, C code which raises the exception could cause a core dump or other "
 "unintended side effects."
 msgstr ""
+"Notez également que la variable :c:data:`SpamError` contient une référence à"
+"la nouvelle classe créée; ceci est intentionnel! Comme l'exception peut être"
+"retirée du module par un code externe, une référence à la classe est nécessaire" 
+"pour assurer qu'il ne sera pas rejeté, causant :c:data:`SpamError` à devenir"
+"un pointeur défaillant. S'il devenait un pointeur défaillant, le C code qui soulève"
+"l'exception peut engendrer un rejet central ou des effets secondaires innatendus." 
 
 #: extending/extending.rst:234
 msgid ""
 "We discuss the use of ``PyMODINIT_FUNC`` as a function return type later in "
 "this sample."
 msgstr ""
+"Nous traiterons de l'utilisation de ``PyMODINIT_FUNC`` comme un type de retour"
+"fonction dans cette section."
 
 #: extending/extending.rst:237
 msgid ""
 "The :exc:`spam.error` exception can be raised in your extension module using "
 "a call to :c:func:`PyErr_SetString` as shown below::"
 msgstr ""
+"L'exception :exc:`spam.error` peut être soulevée dans l'extension de votre module"
+"en appelant :c:func:`PyErr_SetString` comme montré ci-dessous::"
 
 #: extending/extending.rst:260
 msgid "Back to the Example"
-msgstr ""
+msgstr "Retour vers l'Exemple"
 
 #: extending/extending.rst:262
 msgid ""
 "Going back to our example function, you should now be able to understand "
 "this statement::"
 msgstr ""
+"En retournant vers notre fonction exemple, vous devriez maintenant être"
+"capable de comprendre cette affirmation::"
 
 #: extending/extending.rst:268
 msgid ""