# Copyright (C) 2001-2018, Python Software Foundation

# For licence information, see README file.

#

msgid ""

msgstr ""

"Project-Id-Version: Python 3\n"

"Report-Msgid-Bugs-To: \n"

"POT-Creation-Date: 2024-10-29 21:40+0100\n"

"PO-Revision-Date: 2023-07-08 12:37+0200\n"

"Last-Translator: Christophe Nanteuil <christophe.nanteuil@gmail.com>\n"

"Language-Team: FRENCH <traductions@lists.afpy.org>\n"

"Language: fr\n"

"MIME-Version: 1.0\n"

"Content-Type: text/plain; charset=UTF-8\n"

"Content-Transfer-Encoding: 8bit\n"

"X-Generator: Poedit 3.2.2\n"

#: faq/programming.rst:5

msgid "Programming FAQ"

msgstr "FAQ de programmation"

#: faq/programming.rst:8

msgid "Contents"

msgstr "Sommaire"

#: faq/programming.rst:12

msgid "General Questions"

msgstr "Questions générales"

#: faq/programming.rst:15

msgid ""

"Is there a source code level debugger with breakpoints, single-stepping, "

"etc.?"

msgstr ""

"Existe-t-il un débogueur de code source avec points d'arrêts, exécution pas-"

"à-pas, etc. ?"

#: faq/programming.rst:58

msgid "Yes."

msgstr "Oui."

#: faq/programming.rst:19

msgid ""

"Several debuggers for Python are described below, and the built-in function :"

"func:`breakpoint` allows you to drop into any of them."

msgstr ""

"Plusieurs débogueurs sont décrits ci-dessous et la fonction native :func:"

"`breakpoint` permet d'utiliser n'importe lequel d'entre eux."

#: faq/programming.rst:22

msgid ""

"The pdb module is a simple but adequate console-mode debugger for Python. It "

"is part of the standard Python library, and is :mod:`documented in the "

"Library Reference Manual <pdb>`. You can also write your own debugger by "

"using the code for pdb as an example."

msgstr ""

"Le module ``pdb`` est un débogueur console simple, mais parfaitement adapté "

"à Python. Il fait partie de la bibliothèque standard de Python, sa "

"documentation se trouve dans le :mod:`manuel de référence <pdb>`. Vous "

"pouvez vous inspirer du code de ``pdb`` pour écrire votre propre débogueur."

#: faq/programming.rst:27

msgid ""

"The IDLE interactive development environment, which is part of the standard "

"Python distribution (normally available as `Tools/scripts/idle3 <https://"

"github.com/python/cpython/blob/main/Tools/scripts/idle3>`_), includes a "

"graphical debugger."

msgstr ""

"L'environnement de développement interactif IDLE, qui est fourni avec la "

"distribution standard de Python (normalement disponible dans `Tools/scripts/"

"idle3 <https://github.com/python/cpython/blob/main/Tools/scripts/idle3>`_) "

"contient un débogueur graphique."

#: faq/programming.rst:32

msgid ""

"PythonWin is a Python IDE that includes a GUI debugger based on pdb. The "

"PythonWin debugger colors breakpoints and has quite a few cool features such "

"as debugging non-PythonWin programs. PythonWin is available as part of "

"`pywin32 <https://github.com/mhammond/pywin32>`_ project and as a part of "

"the `ActivePython <https://www.activestate.com/products/python/>`_ "

"distribution."

msgstr ""

"*PythonWin* est un environnement de développement intégré (EDI) Python qui "

"embarque un débogueur graphique basé sur ``pdb``. Le débogueur *PythonWin* "

"colore les points d'arrêts et possède quelques fonctionnalités sympathiques, "

"comme la possibilité de déboguer des programmes développés sans "

"*PythonWin*. *PythonWin* est disponible dans le projet `pywin32 <https://"

"github.com/mhammond/pywin32>`_ et fait partie de la distribution "

"`ActivePython <https://www.activestate.com/products/python/>`_."

#: faq/programming.rst:39

msgid ""

"`Eric <https://eric-ide.python-projects.org/>`_ is an IDE built on PyQt and "

"the Scintilla editing component."

msgstr ""

"`Eric <https://eric-ide.python-projects.org/>`_ est un EDI basé sur PyQt et "

"l'outil d'édition Scintilla."

#: faq/programming.rst:42

msgid ""

"`trepan3k <https://github.com/rocky/python3-trepan/>`_ is a gdb-like "

"debugger."

msgstr ""

"`trepan3k <https://github.com/rocky/python3-trepan/>`_ est un débogueur "

"semblable à GDB."

#: faq/programming.rst:44

msgid ""

"`Visual Studio Code <https://code.visualstudio.com/>`_ is an IDE with "

"debugging tools that integrates with version-control software."

msgstr ""

"`Visual Studio Code <https://code.visualstudio.com/>`_ est un EDI qui "

"contient des outils de débogage. Il sait interagir avec les outils de "

"gestion de versions."

#: faq/programming.rst:47

msgid ""

"There are a number of commercial Python IDEs that include graphical "

"debuggers. They include:"

msgstr ""

"Il existe de nombreux EDI Python propriétaires qui embarquent un débogueur "

"graphique, notamment :"

#: faq/programming.rst:50

msgid "`Wing IDE <https://wingware.com/>`_"

msgstr "`Wing IDE <https://wingware.com/>`_ ;"

#: faq/programming.rst:51

msgid "`Komodo IDE <https://www.activestate.com/products/komodo-ide/>`_"

msgstr "`Komodo IDE <https://www.activestate.com/products/komodo-ide/>`_ ;"

#: faq/programming.rst:52

msgid "`PyCharm <https://www.jetbrains.com/pycharm/>`_"

msgstr "`PyCharm <https://www.jetbrains.com/pycharm/>`_ ;"

#: faq/programming.rst:56

msgid "Are there tools to help find bugs or perform static analysis?"

msgstr ""

"Existe-t-il des outils pour aider à trouver des bogues ou faire de l'analyse "

"statique de code ?"

#: faq/programming.rst:60

msgid ""

"`Pylint <https://pylint.pycqa.org/en/latest/index.html>`_ and `Pyflakes "

"<https://github.com/PyCQA/pyflakes>`_ do basic checking that will help you "

"catch bugs sooner."

msgstr ""

"`Pylint <https://pylint.pycqa.org/en/latest/index.html>`_ et `Pyflakes "

"<https://github.com/PyCQA/pyflakes>`_ font des vérifications de base et vous "

"aideront à trouver des bogues plus tôt."

#: faq/programming.rst:64

#, fuzzy

msgid ""

"Static type checkers such as `Mypy <https://mypy-lang.org/>`_, `Pyre "

"<https://pyre-check.org/>`_, and `Pytype <https://github.com/google/"

"pytype>`_ can check type hints in Python source code."

msgstr ""

"Les vérificateurs statiques de typage comme `Mypy <http://mypy-lang.org/>`_, "

"`Pyre <https://pyre-check.org/>`_, et `Pytype <https://github.com/google/"

"pytype>`_ peuvent vérifier les indications de type dans du code source "

"Python."

#: faq/programming.rst:73

msgid "How can I create a stand-alone binary from a Python script?"

msgstr "Comment créer un binaire autonome à partir d'un script Python ?"

#: faq/programming.rst:75

msgid ""

"You don't need the ability to compile Python to C code if all you want is a "

"stand-alone program that users can download and run without having to "

"install the Python distribution first. There are a number of tools that "

"determine the set of modules required by a program and bind these modules "

"together with a Python binary to produce a single executable."

msgstr ""

"Pour créer un programme autonome, c'est-à-dire un programme que n'importe "

"qui peut télécharger et exécuter sans avoir à installer une distribution "

"Python au préalable, il n'est pas nécessaire de compiler du code Python en "

"code C. Il existe en effet plusieurs outils qui déterminent les modules "

"requis par un programme et lient ces modules avec un binaire Python pour "

"produire un seul exécutable."

#: faq/programming.rst:81

msgid ""

"One is to use the freeze tool, which is included in the Python source tree "

"as `Tools/freeze <https://github.com/python/cpython/tree/main/Tools/"

"freeze>`_. It converts Python byte code to C arrays; with a C compiler you "

"can embed all your modules into a new program, which is then linked with the "

"standard Python modules."

msgstr ""

"Un de ces outils est *freeze*, qui se trouve dans `Tools/freeze <https://"

"github.com/python/cpython/tree/main/Tools/freeze>`_ de l'arborescence des "

"sources de Python. Il convertit le code intermédiaire (*bytecode*) Python en "

"tableaux C ; avec un compilateur C, vous pouvez intégrer tous vos modules "

"dans un nouveau programme, qui est ensuite lié aux modules standards Python."

#: faq/programming.rst:87

msgid ""

"It works by scanning your source recursively for import statements (in both "

"forms) and looking for the modules in the standard Python path as well as in "

"the source directory (for built-in modules). It then turns the bytecode for "

"modules written in Python into C code (array initializers that can be turned "

"into code objects using the marshal module) and creates a custom-made config "

"file that only contains those built-in modules which are actually used in "

"the program. It then compiles the generated C code and links it with the "

"rest of the Python interpreter to form a self-contained binary which acts "

"exactly like your script."

msgstr ""

"Il fonctionne en cherchant de manière récursive les instructions "

"d'importation (sous les deux formes) dans le code source et en recherchant "

"ces modules dans le chemin Python standard ainsi que dans le répertoire "

"source (pour les modules natifs). Il transforme ensuite le code "

"intermédiaire des modules écrits en Python en code C (des tableaux pré-"

"remplis qui peuvent être transformés en objets code à l'aide du module "

"*marshal*) et crée un fichier de configuration personnalisé qui contient "

"uniquement les modules natifs qui sont réellement utilisés dans le "

"programme. Il compile ensuite le code C généré et le lie au reste de "

"l'interpréteur Python pour former un binaire autonome qui fait exactement la "

"même chose que le script."

#: faq/programming.rst:96

msgid ""

"The following packages can help with the creation of console and GUI "

"executables:"

msgstr ""

"Voici quelques paquets qui permettent de créer des exécutables en ligne de "

"commande comme graphiques :"

#: faq/programming.rst:99

msgid "`Nuitka <https://nuitka.net/>`_ (Cross-platform)"

msgstr "`Nuitka <https://nuitka.net/>`_ (multiplateformes) ;"

#: faq/programming.rst:100

#, fuzzy

msgid "`PyInstaller <https://pyinstaller.org/>`_ (Cross-platform)"

msgstr "`PyInstaller <http://www.pyinstaller.org/>`_ (multiplateformes) ;"

#: faq/programming.rst:101

msgid ""

"`PyOxidizer <https://pyoxidizer.readthedocs.io/en/stable/>`_ (Cross-platform)"

msgstr ""

"`PyOxidizer <https://pyoxidizer.readthedocs.io/en/stable/>`_ (multi-"

"plateforme) ;"

#: faq/programming.rst:102

msgid ""

"`cx_Freeze <https://marcelotduarte.github.io/cx_Freeze/>`_ (Cross-platform)"

msgstr ""

"`cx_Freeze <https://marcelotduarte.github.io/cx_Freeze/>`_ (multi-"

"plateforme) ;"

#: faq/programming.rst:103

msgid "`py2app <https://github.com/ronaldoussoren/py2app>`_ (macOS only)"

msgstr ""

"`py2app <https://github.com/ronaldoussoren/py2app>`_ (uniquement pour "

"macOS) ;"

#: faq/programming.rst:104

msgid "`py2exe <https://www.py2exe.org/>`_ (Windows only)"

msgstr "`py2exe <https://www.py2exe.org/>`_ (uniquement pour Windows)."

#: faq/programming.rst:107

msgid "Are there coding standards or a style guide for Python programs?"

msgstr ""

"Existe-t-il des normes de développement ou un guide de style pour écrire des "

"programmes Python ?"

#: faq/programming.rst:109

msgid ""

"Yes. The coding style required for standard library modules is documented "

"as :pep:`8`."

msgstr ""

"Oui. Le style de développement que les modules de la bibliothèque standard "

"doivent obligatoirement respecter est documenté dans la :pep:`8`."

#: faq/programming.rst:114

msgid "Core Language"

msgstr "Fondamentaux"

#: faq/programming.rst:119

msgid "Why am I getting an UnboundLocalError when the variable has a value?"

msgstr ""

"Pourquoi une UnboundLocalError est levée alors qu'une variable a une valeur ?"

#: faq/programming.rst:121

msgid ""

"It can be a surprise to get the :exc:`UnboundLocalError` in previously "

"working code when it is modified by adding an assignment statement somewhere "

"in the body of a function."

msgstr ""

"Il est parfois surprenant d'obtenir une :exc:`UnboundLocalError` dans du "

"code jusqu'à présent correct, quand celui-ci est modifié en ajoutant une "

"instruction d'affectation quelque part dans le corps d'une fonction."

#: faq/programming.rst:125

msgid "This code:"

msgstr "Le code suivant :"

#: faq/programming.rst:134

msgid "works, but this code:"

msgstr "fonctionne, mais le suivant :"

#: faq/programming.rst:141

#, fuzzy

msgid "results in an :exc:`!UnboundLocalError`:"

msgstr "lève une UnboundLocalError :"

#: faq/programming.rst:148

msgid ""

"This is because when you make an assignment to a variable in a scope, that "

"variable becomes local to that scope and shadows any similarly named "

"variable in the outer scope. Since the last statement in foo assigns a new "

"value to ``x``, the compiler recognizes it as a local variable. "

"Consequently when the earlier ``print(x)`` attempts to print the "

"uninitialized local variable and an error results."

msgstr ""

"Cela est dû au fait que, quand une variable est affectée dans un contexte, "

"cette variable devient locale à ce contexte et remplace toute variable du "

"même nom du contexte appelant. Vu que la dernière instruction dans *foo* "

"affecte une nouvelle valeur à ``x``, le compilateur la traite comme une "

"nouvelle variable. Par conséquent, quand le ``print(x)`` essaye d'afficher "

"la variable non initialisée, une erreur se produit."

#: faq/programming.rst:155

msgid ""

"In the example above you can access the outer scope variable by declaring it "

"global:"

msgstr ""

"Dans l'exemple ci-dessus, la variable du contexte appelant reste accessible "

"en la déclarant globale :"

#: faq/programming.rst:167

msgid ""

"This explicit declaration is required in order to remind you that (unlike "

"the superficially analogous situation with class and instance variables) you "

"are actually modifying the value of the variable in the outer scope:"

msgstr ""

"Cette déclaration explicite est obligatoire pour se rappeler que "

"(contrairement au cas à peu près similaire avec des variables de classe et "

"d'instance), c'est la valeur de la variable du contexte appelant qui est "

"modifiée :"

#: faq/programming.rst:174

msgid ""

"You can do a similar thing in a nested scope using the :keyword:`nonlocal` "

"keyword:"

msgstr ""

"Une alternative dans un contexte imbriqué consiste à utiliser le mot-clé :"

"keyword:`nonlocal` :"

#: faq/programming.rst:192

msgid "What are the rules for local and global variables in Python?"

msgstr ""

"Quelles sont les règles pour les variables locales et globales en Python ?"

#: faq/programming.rst:194

msgid ""

"In Python, variables that are only referenced inside a function are "

"implicitly global. If a variable is assigned a value anywhere within the "

"function's body, it's assumed to be a local unless explicitly declared as "

"global."

msgstr ""

"En Python, si une variable n'est pas modifiée dans une fonction mais "

"seulement lue, elle est implicitement considérée comme globale. Si une "

"valeur lui est affectée, elle est considérée locale (sauf si elle est "

"explicitement déclarée globale)."

#: faq/programming.rst:198

msgid ""

"Though a bit surprising at first, a moment's consideration explains this. "

"On one hand, requiring :keyword:`global` for assigned variables provides a "

"bar against unintended side-effects. On the other hand, if ``global`` was "

"required for all global references, you'd be using ``global`` all the time. "

"You'd have to declare as global every reference to a built-in function or to "

"a component of an imported module. This clutter would defeat the usefulness "

"of the ``global`` declaration for identifying side-effects."

msgstr ""

"Bien que surprenant au premier abord, ce choix s'explique facilement. D'une "

"part, exiger :keyword:`global` pour des variables affectées est une "

"protection contre des effets de bord inattendus. D'autre part, si ``global`` "

"était obligatoire pour toutes les références à des objets globaux, il "

"faudrait mettre ``global`` partout, car il faudrait dans ce cas déclarer "

"globale chaque référence à une fonction native ou à un composant d'un module "

"importé. Le codé serait alors truffé de déclarations ``global``, ce qui "

"nuirait à leur raison d'être : identifier les effets de bords."

#: faq/programming.rst:208

msgid ""

"Why do lambdas defined in a loop with different values all return the same "

"result?"

msgstr ""

"Pourquoi des expressions lambda définies dans une boucle avec des valeurs "

"différentes retournent-elles le même résultat ?"

#: faq/programming.rst:210

msgid ""

"Assume you use a for loop to define a few different lambdas (or even plain "

"functions), e.g.::"

msgstr ""

"Supposons que l'on utilise une boucle itérative pour définir des expressions "

"lambda (voire des fonctions) différentes, par exemple ::"

#: faq/programming.rst:213

msgid ""

">>> squares = []\n"

">>> for x in range(5):\n"

"... squares.append(lambda: x**2)"

msgstr ""

#: faq/programming.rst:217

msgid ""

"This gives you a list that contains 5 lambdas that calculate ``x**2``. You "

"might expect that, when called, they would return, respectively, ``0``, "

"``1``, ``4``, ``9``, and ``16``. However, when you actually try you will "

"see that they all return ``16``::"

msgstr ""

"Le code précédent crée une liste de 5 expressions lambda qui calculent "

"chacune ``x**2``. En les exécutant, on pourrait s'attendre à obtenir ``0``, "

"``1``, ``4``, ``9`` et ``16``. Elles renvoient en réalité toutes ``16`` ::"

#: faq/programming.rst:222

msgid ""

">>> squares[2]()\n"

"16\n"

">>> squares[4]()\n"

"16"

msgstr ""

#: faq/programming.rst:227

msgid ""

"This happens because ``x`` is not local to the lambdas, but is defined in "

"the outer scope, and it is accessed when the lambda is called --- not when "

"it is defined. At the end of the loop, the value of ``x`` is ``4``, so all "

"the functions now return ``4**2``, i.e. ``16``. You can also verify this by "

"changing the value of ``x`` and see how the results of the lambdas change::"

msgstr ""

"Ceci s'explique par le fait que ``x`` n'est pas une variable locale aux "

"expressions, mais est définie dans le contexte appelant. Elle est lue à "

"l'appel de l'expression lambda – et non au moment où cette expression est "

"définie. À la fin de la boucle, ``x`` vaut ``4``, donc toutes les fonctions "

"renvoient ``4*2``, c.-à-d. ``16``. Ceci se vérifie également en changeant la "

"valeur de ``x`` et en constatant que les résultats sont modifiés ::"

#: faq/programming.rst:233

msgid ""

">>> x = 8\n"

">>> squares[2]()\n"

"64"

msgstr ""

#: faq/programming.rst:237

msgid ""

"In order to avoid this, you need to save the values in variables local to "

"the lambdas, so that they don't rely on the value of the global ``x``::"

msgstr ""

"Pour éviter ce phénomène, les valeurs doivent être stockées dans des "

"variables locales aux expressions lambda pour que celles-ci ne se basent "

"plus sur la variable globale ``x`` ::"

#: faq/programming.rst:240

msgid ""

">>> squares = []\n"

">>> for x in range(5):\n"

"... squares.append(lambda n=x: n**2)"

msgstr ""

#: faq/programming.rst:244

msgid ""

"Here, ``n=x`` creates a new variable ``n`` local to the lambda and computed "

"when the lambda is defined so that it has the same value that ``x`` had at "

"that point in the loop. This means that the value of ``n`` will be ``0`` in "

"the first lambda, ``1`` in the second, ``2`` in the third, and so on. "

"Therefore each lambda will now return the correct result::"

msgstr ""

"Dans ce code, ``n=x`` crée une nouvelle variable ``n``, locale à "

"l'expression. Cette variable est évaluée quand l'expression est définie donc "

"``n`` a la même valeur que ``x`` à ce moment. La valeur de ``n`` est donc "

"``0`` dans la première lambda, ``1`` dans la deuxième, ``2`` dans la "

"troisième et ainsi de suite. Chaque expression lambda renvoie donc le "

"résultat correct ::"

#: faq/programming.rst:250

msgid ""

">>> squares[2]()\n"

"4\n"

">>> squares[4]()\n"

"16"

msgstr ""

#: faq/programming.rst:255

msgid ""

"Note that this behaviour is not peculiar to lambdas, but applies to regular "

"functions too."

msgstr ""

"Ce comportement n'est pas propre aux expressions lambda, mais s'applique "

"aussi aux fonctions normales."

#: faq/programming.rst:260

msgid "How do I share global variables across modules?"

msgstr "Comment partager des variables globales entre modules ?"

#: faq/programming.rst:262

msgid ""

"The canonical way to share information across modules within a single "

"program is to create a special module (often called config or cfg). Just "

"import the config module in all modules of your application; the module then "

"becomes available as a global name. Because there is only one instance of "

"each module, any changes made to the module object get reflected "

"everywhere. For example:"

msgstr ""

"La manière standard de partager des informations entre modules d'un même "

"programme est de créer un module spécial (souvent appelé *config* ou *cfg*) "

"et de l'importer dans tous les modules de l'application ; le module devient "

"accessible depuis l'espace de nommage global. Vu qu'il n'y a qu'une instance "

"de chaque module, tout changement dans l'instance est propagé partout. Par "

"exemple :"

#: faq/programming.rst:268

msgid "config.py::"

msgstr "*config.py* ::"

#: faq/programming.rst:270

msgid "x = 0 # Default value of the 'x' configuration setting"

msgstr ""

#: faq/programming.rst:272

msgid "mod.py::"

msgstr "*mod.py* ::"

#: faq/programming.rst:274

msgid ""

"import config\n"

"config.x = 1"

msgstr ""

#: faq/programming.rst:277

msgid "main.py::"

msgstr "*main.py* ::"

#: faq/programming.rst:279

msgid ""

"import config\n"

"import mod\n"

"print(config.x)"

msgstr ""

#: faq/programming.rst:283

msgid ""

"Note that using a module is also the basis for implementing the singleton "

"design pattern, for the same reason."

msgstr ""

"Pour les mêmes raisons, l'utilisation d'un module est aussi à la base de "

"l'implémentation du patron de conception singleton."

#: faq/programming.rst:288

msgid "What are the \"best practices\" for using import in a module?"

msgstr ""

"Quelles sont les « bonnes pratiques » pour utiliser import dans un module ?"

#: faq/programming.rst:290

msgid ""

"In general, don't use ``from modulename import *``. Doing so clutters the "

"importer's namespace, and makes it much harder for linters to detect "

"undefined names."

msgstr ""

"De manière générale, il ne faut pas faire ``from modulename import *``. Ceci "

"encombre l'espace de nommage de l'importateur et rend la détection de noms "

"non-définis beaucoup plus ardue pour les analyseurs de code."

#: faq/programming.rst:294

msgid ""

"Import modules at the top of a file. Doing so makes it clear what other "

"modules your code requires and avoids questions of whether the module name "

"is in scope. Using one import per line makes it easy to add and delete "

"module imports, but using multiple imports per line uses less screen space."

msgstr ""

"Les modules doivent être importés au début d'un fichier. Ceci permet "

"d'afficher clairement de quels modules le code à besoin et évite de se "

"demander si le module est dans le contexte. Faire un seul ``import`` par "

"ligne rend l'ajout et la suppression d'une importation de module plus aisé, "

"mais importer plusieurs modules sur une même ligne prend moins d'espace."

#: faq/programming.rst:299

msgid "It's good practice if you import modules in the following order:"

msgstr "Il est recommandé d'importer les modules dans l'ordre suivant :"

#: faq/programming.rst:301

msgid ""

"standard library modules -- e.g. :mod:`sys`, :mod:`os`, :mod:`argparse`, :"

"mod:`re`"

msgstr ""

"les modules de la bibliothèque standard — p. ex. :mod:`sys`, :mod:`os`, :mod:"

"`getopt`, :mod:`re`"

#: faq/programming.rst:302

msgid ""

"third-party library modules (anything installed in Python's site-packages "

"directory) -- e.g. :mod:`!dateutil`, :mod:`!requests`, :mod:`!PIL.Image`"

msgstr ""

"les modules externes (tout ce qui est installé dans le dossier *site-"

"packages* de Python) — par exemple :mod:`!dateutil`, :mod:`!requests`, :mod:"

"`!PIL.Image`"

#: faq/programming.rst:304

msgid "locally developed modules"

msgstr "les modules développés en local"

#: faq/programming.rst:306

msgid ""

"It is sometimes necessary to move imports to a function or class to avoid "

"problems with circular imports. Gordon McMillan says:"

msgstr ""

"Il est parfois nécessaire de déplacer des importations dans une fonction ou "

"une classe pour éviter les problèmes d'importations circulaires. Comme le "

"souligne Gordon McMillan :"

#: faq/programming.rst:309

msgid ""

"Circular imports are fine where both modules use the \"import <module>\" "

"form of import. They fail when the 2nd module wants to grab a name out of "

"the first (\"from module import name\") and the import is at the top level. "

"That's because names in the 1st are not yet available, because the first "

"module is busy importing the 2nd."

msgstr ""

"Il n'y a aucun souci à faire des importations circulaires tant que les deux "

"modules utilisent la forme ``import <module>``. Ça ne pose problème que si "

"le second module cherche à récupérer un nom du premier module (*\"from "

"module import name\"*) et que l'importation est dans l'espace de nommage du "

"fichier. Les noms du premier module ne sont en effet pas encore disponibles "

"car le premier module est occupé à importer le second."

#: faq/programming.rst:315

msgid ""

"In this case, if the second module is only used in one function, then the "

"import can easily be moved into that function. By the time the import is "

"called, the first module will have finished initializing, and the second "

"module can do its import."

msgstr ""

"Dans ce cas, si le second module n'est utilisé que dans une fonction, "

"l'importation peut facilement être déplacée dans cette fonction. Au moment "

"où l'importation sera appelée, le premier module aura fini de s'initialiser "

"et le second pourra faire son importation."

#: faq/programming.rst:320

msgid ""

"It may also be necessary to move imports out of the top level of code if "

"some of the modules are platform-specific. In that case, it may not even be "

"possible to import all of the modules at the top of the file. In this case, "

"importing the correct modules in the corresponding platform-specific code is "

"a good option."

msgstr ""

"Il peut parfois être nécessaire de déplacer des importations de modules hors "

"de l'espace de plus haut niveau du code si certains de ces modules dépendent "

"de la machine utilisée. Dans ce cas de figure, il est parfois impossible "

"d'importer tous les modules au début du fichier. Dans ce cas, il est "

"recommandé d'importer les modules adéquats dans le code spécifique à la "

"machine."

#: faq/programming.rst:325

msgid ""

"Only move imports into a local scope, such as inside a function definition, "

"if it's necessary to solve a problem such as avoiding a circular import or "

"are trying to reduce the initialization time of a module. This technique is "

"especially helpful if many of the imports are unnecessary depending on how "

"the program executes. You may also want to move imports into a function if "

"the modules are only ever used in that function. Note that loading a module "

"the first time may be expensive because of the one time initialization of "

"the module, but loading a module multiple times is virtually free, costing "

"only a couple of dictionary lookups. Even if the module name has gone out "

"of scope, the module is probably available in :data:`sys.modules`."

msgstr ""

"Les importations ne devraient être déplacées dans un espace de nommage "

"local, comme dans la définition d'une fonction, que si cela est nécessaire "

"pour résoudre un problème comme éviter des dépendances circulaires ou "

"réduire le temps d'initialisation d'un module. Cette technique est "

"particulièrement utile si la majorité des importations est superflue selon "

"le flux d'exécution du programme. Il est également pertinent de déplacer des "

"importations dans une fonction si le module n'est utilisé qu'au sein de "

"cette fonction. Le premier chargement d'un module peut être coûteux à cause "

"du coût fixe d'initialisation d'un module, mais charger un module plusieurs "

"fois est quasiment gratuit, cela ne coûte que quelques indirections dans un "

"dictionnaire. Même si le nom du module est sorti du contexte courant, le "

"module est probablement disponible dans :data:`sys.modules`."

#: faq/programming.rst:338

msgid "Why are default values shared between objects?"

msgstr "Pourquoi les arguments par défaut sont-ils partagés entre les objets ?"

#: faq/programming.rst:340

msgid ""

"This type of bug commonly bites neophyte programmers. Consider this "

"function::"

msgstr ""

"C'est un problème que rencontrent souvent les programmeurs débutants. "

"Examinons la fonction suivante ::"

#: faq/programming.rst:342

msgid ""

"def foo(mydict={}): # Danger: shared reference to one dict for all calls\n"

" ... compute something ...\n"

" mydict[key] = value\n"

" return mydict"

msgstr ""

#: faq/programming.rst:347

msgid ""

"The first time you call this function, ``mydict`` contains a single item. "

"The second time, ``mydict`` contains two items because when ``foo()`` begins "

"executing, ``mydict`` starts out with an item already in it."

msgstr ""

"Au premier appel de cette fonction, ``mydict`` ne contient qu'un seul "

"élément. Au second appel, ``mydict`` contient deux éléments car quand "

"``foo()`` commence son exécution, ``mydict`` contient déjà un élément."

#: faq/programming.rst:351

msgid ""

"It is often expected that a function call creates new objects for default "

"values. This is not what happens. Default values are created exactly once, "

"when the function is defined. If that object is changed, like the "

"dictionary in this example, subsequent calls to the function will refer to "

"this changed object."

msgstr ""

"On est souvent amené à croire qu'un appel de fonction créé des nouveaux "

"objets pour les valeurs par défaut. Ce n'est pas le cas. Les valeurs par "

"défaut ne sont créées qu'une et une seule fois, au moment où la fonction est "

"définie. Si l'objet est modifié, comme le dictionnaire dans cet exemple, les "

"appels suivants à cette fonction font référence à l'objet ainsi modifié."

#: faq/programming.rst:356

msgid ""

"By definition, immutable objects such as numbers, strings, tuples, and "

"``None``, are safe from change. Changes to mutable objects such as "

"dictionaries, lists, and class instances can lead to confusion."

msgstr ""

"Par définition, les objets immuables comme les nombres, les chaînes de "

"caractères, les *n*-uplets et ``None`` ne sont pas modifiés. Les changements "

"sur des objets modifiables comme les dictionnaires, les listes et les "

"instances de classe peuvent porter à confusion."

#: faq/programming.rst:360

msgid ""

"Because of this feature, it is good programming practice to not use mutable "

"objects as default values. Instead, use ``None`` as the default value and "

"inside the function, check if the parameter is ``None`` and create a new "

"list/dictionary/whatever if it is. For example, don't write::"

msgstr ""

"En raison de cette fonctionnalité, il vaut mieux ne pas utiliser d'objets "

"modifiables comme valeurs par défaut. Il vaut mieux utiliser ``None`` comme "

"valeur par défaut et, à l'intérieur de la fonction, vérifier si le paramètre "

"est à ``None`` et créer une nouvelle liste, dictionnaire ou autre, le cas "

"échéant. Par exemple, il ne faut pas écrire ::"

#: faq/programming.rst:365

msgid ""

"def foo(mydict={}):\n"

" ..."

msgstr ""

#: faq/programming.rst:368

msgid "but::"

msgstr "mais plutôt ::"

#: faq/programming.rst:370

msgid ""

"def foo(mydict=None):\n"

" if mydict is None:\n"

" mydict = {} # create a new dict for local namespace"

msgstr ""

#: faq/programming.rst:374

msgid ""

"This feature can be useful. When you have a function that's time-consuming "

"to compute, a common technique is to cache the parameters and the resulting "

"value of each call to the function, and return the cached value if the same "

"value is requested again. This is called \"memoizing\", and can be "

"implemented like this::"

msgstr ""

"Cette fonctionnalité a une utilité. Il est courant de mettre en cache les "

"paramètres et la valeur de retour de chacun des appels d'une fonction "

"coûteuse à exécuter, et de renvoyer la valeur stockée en cache si le même "

"appel est ré-effectué. C'est la technique dite de « mémoïsation », qui "

"s'implémente de la manière suivante ::"

#: faq/programming.rst:379

msgid ""

"# Callers can only provide two parameters and optionally pass _cache by "

"keyword\n"

"def expensive(arg1, arg2, *, _cache={}):\n"

" if (arg1, arg2) in _cache:\n"

" return _cache[(arg1, arg2)]\n"

"\n"

" # Calculate the value\n"

" result = ... expensive computation ...\n"

" _cache[(arg1, arg2)] = result # Store result in the cache\n"

" return result"

msgstr ""

#: faq/programming.rst:389

msgid ""

"You could use a global variable containing a dictionary instead of the "

"default value; it's a matter of taste."

msgstr ""

"Il est possible d'utiliser une variable globale contenant un dictionnaire à "

"la place de la valeur par défaut ; ce n'est qu'une question de goût."

#: faq/programming.rst:394

msgid ""

"How can I pass optional or keyword parameters from one function to another?"

msgstr ""

"Comment passer des paramètres optionnels ou nommés d'une fonction à l'autre ?"

#: faq/programming.rst:396

msgid ""

"Collect the arguments using the ``*`` and ``**`` specifiers in the "

"function's parameter list; this gives you the positional arguments as a "

"tuple and the keyword arguments as a dictionary. You can then pass these "

"arguments when calling another function by using ``*`` and ``**``::"

msgstr ""

"Il faut récupérer les arguments en utilisant les sélecteurs ``*`` et ``**`` "

"dans la liste des paramètres de la fonction ; ceci donne les arguments "

"positionnels sous la forme d'un *n*-uplet et les arguments nommés sous forme "

"de dictionnaire. Ces arguments peuvent être passés à une autre fonction en "

"utilisant ``*`` et ``**`` ::"

#: faq/programming.rst:401

msgid ""

"def f(x, *args, **kwargs):\n"

" ...\n"

" kwargs['width'] = '14.3c'\n"

" ...\n"

" g(x, *args, **kwargs)"

msgstr ""

#: faq/programming.rst:415

msgid "What is the difference between arguments and parameters?"

msgstr "Quelle est la différence entre les arguments et les paramètres ?"

#: faq/programming.rst:417

msgid ""

":term:`Parameters <parameter>` are defined by the names that appear in a "

"function definition, whereas :term:`arguments <argument>` are the values "

"actually passed to a function when calling it. Parameters define what :term:"

"`kind of arguments <parameter>` a function can accept. For example, given "

"the function definition::"

msgstr ""

"Les :term:`paramètres <parameter>` sont les noms qui apparaissent dans une "

"définition de fonction, alors que les :term:`arguments <argument>` sont les "

"valeurs qui sont réellement passées à une fonction lors de l'appel de celle-"

"ci. Les paramètres définissent les :term:`types d'arguments <parameter>` "

"qu'une fonction accepte. Ainsi, avec la définition de fonction suivante ::"

#: faq/programming.rst:423

msgid ""

"def func(foo, bar=None, **kwargs):\n"

" pass"

msgstr ""

#: faq/programming.rst:426

msgid ""

"*foo*, *bar* and *kwargs* are parameters of ``func``. However, when calling "

"``func``, for example::"

msgstr ""

"*foo*, *bar* et *kwargs* sont des paramètres de ``func``. Mais à l'appel de "

"``func`` avec, par exemple ::"

#: faq/programming.rst:429

msgid "func(42, bar=314, extra=somevar)"

msgstr ""

#: faq/programming.rst:431

msgid "the values ``42``, ``314``, and ``somevar`` are arguments."

msgstr "les valeurs ``42``, ``314``, et ``somevar`` sont des arguments."

#: faq/programming.rst:435

msgid "Why did changing list 'y' also change list 'x'?"

msgstr "Pourquoi modifier la liste 'y' modifie aussi la liste 'x' ?"

#: faq/programming.rst:437

msgid "If you wrote code like::"

msgstr "Si vous avez écrit du code comme ::"

#: faq/programming.rst:439

msgid ""

">>> x = []\n"

">>> y = x\n"

">>> y.append(10)\n"

">>> y\n"

"[10]\n"

">>> x\n"

"[10]"

msgstr ""

#: faq/programming.rst:447

msgid ""

"you might be wondering why appending an element to ``y`` changed ``x`` too."

msgstr ""

"vous vous demandez peut-être pourquoi l'ajout d'un élément à ``y`` a aussi "

"changé ``x``."

#: faq/programming.rst:449

msgid "There are two factors that produce this result:"

msgstr "Il y a deux raisons qui conduisent à ce comportement :"

#: faq/programming.rst:451

msgid ""

"Variables are simply names that refer to objects. Doing ``y = x`` doesn't "

"create a copy of the list -- it creates a new variable ``y`` that refers to "

"the same object ``x`` refers to. This means that there is only one object "

"(the list), and both ``x`` and ``y`` refer to it."

msgstr ""

"Les variables ne sont que des noms qui font référence à des objets. La ligne "

"``y = x`` ne crée pas une copie de la liste — elle crée une nouvelle "

"variable ``y`` qui pointe sur le même objet que ``x``. Ceci signifie qu'il "

"n'existe qu'un seul objet (la liste) auquel ``x`` et ``y`` font référence."

#: faq/programming.rst:455

msgid ""

"Lists are :term:`mutable`, which means that you can change their content."

msgstr ""

"Les listes sont des :term:`mutable`, ce qui signifie que leur contenu peut "

"être modifié."

#: faq/programming.rst:457

#, fuzzy

msgid ""

"After the call to :meth:`!append`, the content of the mutable object has "

"changed from ``[]`` to ``[10]``. Since both the variables refer to the same "

"object, using either name accesses the modified value ``[10]``."

msgstr ""

"Après l'appel de :meth:`~list.append`, le contenu de l'objet mutable est "

"passé de ``[]`` à ``[10]``. Vu que les deux variables font référence au même "

"objet, il est possible d'accéder à la valeur modifiée ``[10]`` avec chacun "

"des noms."

#: faq/programming.rst:461

msgid "If we instead assign an immutable object to ``x``::"

msgstr "Si au contraire, on affecte un objet immuable à ``x`` ::"

#: faq/programming.rst:463

msgid ""

">>> x = 5 # ints are immutable\n"

">>> y = x\n"

">>> x = x + 1 # 5 can't be mutated, we are creating a new object here\n"

">>> x\n"

"6\n"

">>> y\n"

"5"

msgstr ""

#: faq/programming.rst:471

msgid ""

"we can see that in this case ``x`` and ``y`` are not equal anymore. This is "

"because integers are :term:`immutable`, and when we do ``x = x + 1`` we are "

"not mutating the int ``5`` by incrementing its value; instead, we are "

"creating a new object (the int ``6``) and assigning it to ``x`` (that is, "

"changing which object ``x`` refers to). After this assignment we have two "

"objects (the ints ``6`` and ``5``) and two variables that refer to them "

"(``x`` now refers to ``6`` but ``y`` still refers to ``5``)."

msgstr ""

"on observe que ``x`` et ``y`` ne sont ici plus égales. Les entiers sont des "

"immuables (:term:`immutable`), et ``x = x + 1`` ne change pas l'entier ``5`` "

"en incrémentant sa valeur. Au contraire, un nouvel objet est créé (l'entier "

"``6``) et affecté à ``x`` (c'est-à-dire qu'on change l'objet auquel fait "

"référence ``x``). Après cette affectation on a deux objets (les entiers "

"``6`` et ``5``) et deux variables qui font référence à ces deux objets "

"(``x`` fait désormais référence à ``6`` mais ``y`` fait toujours référence à "

"``5``)."

#: faq/programming.rst:479

msgid ""

"Some operations (for example ``y.append(10)`` and ``y.sort()``) mutate the "

"object, whereas superficially similar operations (for example ``y = y + "

"[10]`` and :func:`sorted(y) <sorted>`) create a new object. In general in "

"Python (and in all cases in the standard library) a method that mutates an "

"object will return ``None`` to help avoid getting the two types of "

"operations confused. So if you mistakenly write ``y.sort()`` thinking it "

"will give you a sorted copy of ``y``, you'll instead end up with ``None``, "

"which will likely cause your program to generate an easily diagnosed error."

msgstr ""

"Certaines opérations (par exemple, ``y.append(10)`` et ``y.sort()``) "

"modifient l'objet, alors que des opérations identiques en apparence (par "

"exemple ``y = y + [10]`` et :func:`sorted(y)`) créent un nouvel objet. En "

"général, en Python, une méthode qui modifie un objet renvoie ``None`` (c'est "

"même systématique dans la bibliothèque standard) pour éviter la confusion "

"entre les deux opérations. Donc écrire par erreur ``y.sort()`` en pensant "

"obtenir une copie triée de ``y`` donne ``None``, ce qui conduit très souvent "

"le programme à générer une erreur facile à diagnostiquer."

#: faq/programming.rst:488

msgid ""

"However, there is one class of operations where the same operation sometimes "

"has different behaviors with different types: the augmented assignment "

"operators. For example, ``+=`` mutates lists but not tuples or ints "

"(``a_list += [1, 2, 3]`` is equivalent to ``a_list.extend([1, 2, 3])`` and "

"mutates ``a_list``, whereas ``some_tuple += (1, 2, 3)`` and ``some_int += "

"1`` create new objects)."

msgstr ""

"Il existe cependant une classe d'opérations qui se comporte différemment "

"selon le type : les opérateurs d'affectation incrémentaux. Par exemple, "

"``+=`` modifie les listes mais pas les *n*-uplets ni les entiers (``a_list "