# Copyright (C) 2001-2018, Python Software Foundation # This file is distributed under the same license as the Python package. # FIRST AUTHOR , YEAR. # msgid "" msgstr "" "Project-Id-Version: Python 3.6\n" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2018-06-28 15:29+0200\n" "PO-Revision-Date: 2018-07-03 20:59+0200\n" "Last-Translator: Julien Palard \n" "Language-Team: \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 2.0.2\n" #: ../Doc/faq/design.rst:3 msgid "Design and History FAQ" msgstr "FAQ histoire et design" #: ../Doc/faq/design.rst:6 msgid "Contents" msgstr "Sommaire" #: ../Doc/faq/design.rst:11 msgid "Why does Python use indentation for grouping of statements?" msgstr "" "Pourquoi Python utilise-t-il l'indentation pour grouper les instructions ?" #: ../Doc/faq/design.rst:13 msgid "" "Guido van Rossum believes that using indentation for grouping is extremely " "elegant and contributes a lot to the clarity of the average Python program. " "Most people learn to love this feature after a while." msgstr "" "Guido van Rossum considère que l'usage de l'indentation pour regrouper les " "blocs d'instruction est élégant et contribue énormément à la clareté globale " "du programme Python. La plupart des gens finissent par aimer cette " "particularité au bout d'un moment." #: ../Doc/faq/design.rst:17 msgid "" "Since there are no begin/end brackets there cannot be a disagreement between " "grouping perceived by the parser and the human reader. Occasionally C " "programmers will encounter a fragment of code like this::" msgstr "" "Comme il n'y a pas d'accolades de début/fin, il ne peut y avoir de " "différence entre le bloc perçu par l'analyseur syntaxique et le lecteur " "humain. Parfois les programmeurs C pourront trouver un morceau de code comme " "celui-ci : ::" #: ../Doc/faq/design.rst:26 msgid "" "Only the ``x++`` statement is executed if the condition is true, but the " "indentation leads you to believe otherwise. Even experienced C programmers " "will sometimes stare at it a long time wondering why ``y`` is being " "decremented even for ``x > y``." msgstr "" "Seule l'instruction ``x++`` sera exécutée si la condition est vraie, mais " "l'indentation pourrait vous faire penser le contraire. Mêmes des " "développeurs C expérimentés resteront pendant un moment à se demander " "pourquoi ``y`` est décrémenté même si ``x > y``." #: ../Doc/faq/design.rst:31 msgid "" "Because there are no begin/end brackets, Python is much less prone to coding-" "style conflicts. In C there are many different ways to place the braces. If " "you're used to reading and writing code that uses one style, you will feel " "at least slightly uneasy when reading (or being required to write) another " "style." msgstr "" "Comme il n'y a pas d'accolades de début/fin, Python est moins sujet aux " "conflits de style de code. En C, on peut placer les accolades de nombreuses " "façons. Si vous êtes habitués à lire et écrire selon un style particulier, " "vous pourriez vous sentir perturbé en lisant (ou en devant écrire) avec un " "autre style." #: ../Doc/faq/design.rst:36 msgid "" "Many coding styles place begin/end brackets on a line by themselves. This " "makes programs considerably longer and wastes valuable screen space, making " "it harder to get a good overview of a program. Ideally, a function should " "fit on one screen (say, 20--30 lines). 20 lines of Python can do a lot more " "work than 20 lines of C. This is not solely due to the lack of begin/end " "brackets -- the lack of declarations and the high-level data types are also " "responsible -- but the indentation-based syntax certainly helps." msgstr "" "Nombre de styles de programmation utilisent des accolades de début/fin sur " "une ligne à part. Cela rend les programmes beaucoup plus longs et fait " "perdre une bonne partie de l'espace visible sur l'écran, empêchant un peu " "d'avoir une vue globale du programme. Idéalement, une fonction doit être " "visible sur un écran (environ 20 ou 30 lignes). 20 lignes de Python peuvent " "faire beaucoup plus que 20 lignes de C. Ce n'est pas seulement dû à " "l'absence d'accolades de début/fin -- l'absence de déclarations et la " "présence de types de haut-niveau en sont également responsables -- mais la " "syntaxe basée sur l'indentation aide sûrement." #: ../Doc/faq/design.rst:46 msgid "Why am I getting strange results with simple arithmetic operations?" msgstr "" "Pourquoi ai-je d'étranges résultats suite à de simples opérations " "arithmétiques ?" #: ../Doc/faq/design.rst:48 msgid "See the next question." msgstr "Voir la question suivante." #: ../Doc/faq/design.rst:52 msgid "Why are floating-point calculations so inaccurate?" msgstr "Pourquoi les calculs à virgules flottantes sont si imprécis ?" #: ../Doc/faq/design.rst:54 msgid "Users are often surprised by results like this::" msgstr "" "Les gens sont très souvent surpris par des résultats comme celui-ci : ::" #: ../Doc/faq/design.rst:59 msgid "" "and think it is a bug in Python. It's not. This has little to do with " "Python, and much more to do with how the underlying platform handles " "floating-point numbers." msgstr "" "et pensent que c'est un *bug* dans Python. Ça ne l'est pas. Ceci n'a " "d'ailleurs que peu à voir avec Python, mais avec la manière dont la " "plateforme sous-jacente gère les nombres à virgule flottante." #: ../Doc/faq/design.rst:63 msgid "" "The :class:`float` type in CPython uses a C ``double`` for storage. A :" "class:`float` object's value is stored in binary floating-point with a fixed " "precision (typically 53 bits) and Python uses C operations, which in turn " "rely on the hardware implementation in the processor, to perform floating-" "point operations. This means that as far as floating-point operations are " "concerned, Python behaves like many popular languages including C and Java." msgstr "" "La classe :class:`float` dans CPython utilise le type double du langage C " "comme stockage. La valeur d'un objet :class:`float` est stockée dans un " "format binaire à virgule flottante avec une précision fixe (généralement 53 " "bits). Python utilise des opérations qui proviennent du langage C qui à leur " "tour reposent sur l'implémentation au niveau du processeur afin d'effectuer " "des opérations en virgule flottante. Cela signifie que dans le cadre des " "opérations sur les nombres à virgule flottante, Python se comporte comme " "beaucoup de langages populaires dont C et Java." #: ../Doc/faq/design.rst:70 msgid "" "Many numbers that can be written easily in decimal notation cannot be " "expressed exactly in binary floating-point. For example, after::" msgstr "" "Beaucoup de nombres pouvant être écrits facilement en notation décimale ne " "peuvent pas s'exprimer de manière exacte en binaire à virgule flottante. Par " "exemple, après : ::" #: ../Doc/faq/design.rst:75 msgid "" "the value stored for ``x`` is a (very good) approximation to the decimal " "value ``1.2``, but is not exactly equal to it. On a typical machine, the " "actual stored value is::" msgstr "" "la valeur stockée pour ``x`` est une (très bonne) approximation de la valeur " "décimale ``1.2``, mais cette valeur n'est pas exacte. Sur une machine " "typique, la valeur stockée est en fait : ::" #: ../Doc/faq/design.rst:81 msgid "which is exactly::" msgstr "qui est, exactement : ::" #: ../Doc/faq/design.rst:85 msgid "" "The typical precision of 53 bits provides Python floats with 15--16 decimal " "digits of accuracy." msgstr "" "La précision typique de 53 bits des *floats* Python permet une précision de " "15--16 décimales." #: ../Doc/faq/design.rst:88 msgid "" "For a fuller explanation, please see the :ref:`floating point arithmetic " "` chapter in the Python tutorial." msgstr "" "Veuillez vous référer au chapitre sur :ref:`floating point arithmetic ` du tutoriel python pour de plus amples informations." #: ../Doc/faq/design.rst:93 msgid "Why are Python strings immutable?" msgstr "Pourquoi les chaînes de caractères Python sont-elles immuables ?" #: ../Doc/faq/design.rst:95 msgid "There are several advantages." msgstr "Il y a plusieurs avantages." #: ../Doc/faq/design.rst:97 msgid "" "One is performance: knowing that a string is immutable means we can allocate " "space for it at creation time, and the storage requirements are fixed and " "unchanging. This is also one of the reasons for the distinction between " "tuples and lists." msgstr "" "La première concerne la performance : savoir qu'une chaîne de caractères est " "immuable signifie que l'allocation mémoire allouée lors de la création de " "cette chaîne est fixe et figée. C'est aussi l'une des raisons pour " "lesquelles on fait la distinction entre les *tuples* et les listes." #: ../Doc/faq/design.rst:102 msgid "" "Another advantage is that strings in Python are considered as \"elemental\" " "as numbers. No amount of activity will change the value 8 to anything else, " "and in Python, no amount of activity will change the string \"eight\" to " "anything else." msgstr "" "Un autre avantage est que les chaînes en Python sont considérées aussi " "\"élémentaires\" que les nombres. Aucun processus ne changera la valeur du " "nombre 8 en autre chose, et en Python, aucun processus changera la chaîne de " "caractère \"huit\" en autre chose." #: ../Doc/faq/design.rst:110 msgid "Why must 'self' be used explicitly in method definitions and calls?" msgstr "" "Pourquoi \"self\" doit-il être explicitement utilisé dans les définitions et " "les appels de méthode ?" #: ../Doc/faq/design.rst:112 msgid "" "The idea was borrowed from Modula-3. It turns out to be very useful, for a " "variety of reasons." msgstr "" "L'idée a été empruntée à Modula-3. Il s'avère être très utile, pour diverses " "raisons." #: ../Doc/faq/design.rst:115 msgid "" "First, it's more obvious that you are using a method or instance attribute " "instead of a local variable. Reading ``self.x`` or ``self.meth()`` makes it " "absolutely clear that an instance variable or method is used even if you " "don't know the class definition by heart. In C++, you can sort of tell by " "the lack of a local variable declaration (assuming globals are rare or " "easily recognizable) -- but in Python, there are no local variable " "declarations, so you'd have to look up the class definition to be sure. " "Some C++ and Java coding standards call for instance attributes to have an " "``m_`` prefix, so this explicitness is still useful in those languages, too." msgstr "" "Tout d'abord, il est plus évident d'utiliser une méthode ou un attribut " "d'instance par exemple au lieu d'une variable locale. Lire ``self.x`` ou " "``self.meth()`` est sans ambiguité sur le fait que c'est une variable " "d'instance ou une méthode qui est utilisée, même si vous ne connaissez pas " "la définition de classe par cœur. En C++, vous pouvez les reconnaitre par " "l'absence d'une déclaration de variable locale (en supposant que les " "variables globales sont rares ou facilement reconnaissables) - mais en " "Python, il n'y a pas de déclarations de variables locales, de sorte que vous " "devez chercher la définition de classe pour être sûr. Certaines normes de " "programmation C++ et Java préfixent les attributs d'instance par ``m_``. " "Cette syntaxe explicite est ainsi utile également pour ces langages." #: ../Doc/faq/design.rst:125 msgid "" "Second, it means that no special syntax is necessary if you want to " "explicitly reference or call the method from a particular class. In C++, if " "you want to use a method from a base class which is overridden in a derived " "class, you have to use the ``::`` operator -- in Python you can write " "``baseclass.methodname(self, )``. This is particularly " "useful for :meth:`__init__` methods, and in general in cases where a derived " "class method wants to extend the base class method of the same name and thus " "has to call the base class method somehow." msgstr "" "Ensuite, ça veut dire qu'aucune syntaxe spéciale n'est nécessaire si vous " "souhaitez explicitement référencer ou appeler la méthode depuis une classe " "en particulier. En C++, si vous utilisez la méthode d'une classe de base " "elle-même surchargée par une classe dérivée, vous devez utiliser l'opérateur " "``::`` -- en Python vous pouvez écrire ``baseclass.methodname(self, " ")``. C'est particulièrement utile pour les méthodes :meth:" "`__init__`, et de manière générale dans les cas où une classe dérivée veut " "étendre la méthode du même nom de la classe de base, devant ainsi appeler la " "méthode de la classe de base d'une certaine manière." #: ../Doc/faq/design.rst:134 msgid "" "Finally, for instance variables it solves a syntactic problem with " "assignment: since local variables in Python are (by definition!) those " "variables to which a value is assigned in a function body (and that aren't " "explicitly declared global), there has to be some way to tell the " "interpreter that an assignment was meant to assign to an instance variable " "instead of to a local variable, and it should preferably be syntactic (for " "efficiency reasons). C++ does this through declarations, but Python doesn't " "have declarations and it would be a pity having to introduce them just for " "this purpose. Using the explicit ``self.var`` solves this nicely. " "Similarly, for using instance variables, having to write ``self.var`` means " "that references to unqualified names inside a method don't have to search " "the instance's directories. To put it another way, local variables and " "instance variables live in two different namespaces, and you need to tell " "Python which namespace to use." msgstr "" "Enfin, pour des variables d'instance, ça résout un problème syntactique pour " "l'assignation : puisque les variables locales en Python sont (par " "définition !) ces variables auxquelles les valeurs sont assignées dans le " "corps d'une fonction (et n'étant pas déclarées explicitement globales), il " "doit y avoir un moyen de dire à l'interpréteur qu'une assignation est censée " "assigner une variable d'instance plutôt qu'une variable locale, et doit de " "préférence être syntactique (pour des raisons d'efficacité). C++ fait ça au " "travers de déclarations, mais Python n'a pas de déclarations et ça serait " "dommage d'avoir à les introduire juste pour cette raison. Utiliser " "explicitement ``self.var`` résout ça avec élégance. Pareillement, pour " "utiliser des variables d'instance, avoir à écrire ``self.var`` signifie que " "les références vers des noms non-qualifiés au sein d'une méthode n'ont pas à " "être cherchés dans l'annuaire d'instances. En d'autres termes, les variables " "locales et les variables d'instance vivent dans deux différents espaces de " "noms, et vous devez dire à Python quel espace de noms utiliser." #: ../Doc/faq/design.rst:150 msgid "Why can't I use an assignment in an expression?" msgstr "Pourquoi ne puis-je pas utiliser d'assignation dans une expression ?" #: ../Doc/faq/design.rst:152 msgid "" "Many people used to C or Perl complain that they want to use this C idiom:" msgstr "" "De nombreuses personnes habituées à C ou Perl se plaignent de vouloir " "utiliser cet idiome C :" #: ../Doc/faq/design.rst:160 msgid "where in Python you're forced to write this::" msgstr "où en Python vous êtes forcé à écrire ceci : ::" #: ../Doc/faq/design.rst:168 msgid "" "The reason for not allowing assignment in Python expressions is a common, " "hard-to-find bug in those other languages, caused by this construct:" msgstr "" "La raison pour ne pas autoriser l'assignation dans les expressions en Python " "est un bug fréquent, et difficile à trouver dans ces autres langages, causé " "par cette construction :" #: ../Doc/faq/design.rst:180 msgid "" "The error is a simple typo: ``x = 0``, which assigns 0 to the variable " "``x``, was written while the comparison ``x == 0`` is certainly what was " "intended." msgstr "" "Cette erreur est une simple coquille : ``x = 0``, qui assigne 0 à la " "variable ``x``, a été écrit alors que la comparaison ``x == 0`` est " "certainement ce qui était souhaité." #: ../Doc/faq/design.rst:183 msgid "" "Many alternatives have been proposed. Most are hacks that save some typing " "but use arbitrary or cryptic syntax or keywords, and fail the simple " "criterion for language change proposals: it should intuitively suggest the " "proper meaning to a human reader who has not yet been introduced to the " "construct." msgstr "" "De nombreuses alternatives ont été proposées. La plupart des hacks " "économisaient de la frappe mais utilisaient d'arbitraires ou cryptiques " "syntaxes ou mot-clés et faillait le simple critère pour proposition de " "changement du langage : ça doit intuitivement suggérer la bonne " "signification au lecteur qui n'a pas encore été introduit à la construction." #: ../Doc/faq/design.rst:188 msgid "" "An interesting phenomenon is that most experienced Python programmers " "recognize the ``while True`` idiom and don't seem to be missing the " "assignment in expression construct much; it's only newcomers who express a " "strong desire to add this to the language." msgstr "" "Un phénomène intéressant est que la plupart des programmeurs Python " "expérimentés reconnaissent l'idiome ``while True`` et ne semblent pas " "manquer l'assignation dans la construction de l'expression; seuls les " "nouveaux-venus expriment un fort désir d'ajouter ceci au langage." #: ../Doc/faq/design.rst:193 msgid "" "There's an alternative way of spelling this that seems attractive but is " "generally less robust than the \"while True\" solution::" msgstr "" "Il y a une manière alternative de faire ça qui semble attrayante mais elle " "est généralement moins robuste que la solution ``while True`` ::" #: ../Doc/faq/design.rst:201 msgid "" "The problem with this is that if you change your mind about exactly how you " "get the next line (e.g. you want to change it into ``sys.stdin.readline()``) " "you have to remember to change two places in your program -- the second " "occurrence is hidden at the bottom of the loop." msgstr "" "Le problème avec ceci est que si vous changez d'avis sur la manière dont " "vous allez récupérer la prochaine ligne (ex : vous voulez changer en ``sys." "stdin.readline()``) vous devez vous souvenir de le changer à deux endroits " "dans votre programme -- la deuxième occurrence est cachée en bas de la " "boucle." #: ../Doc/faq/design.rst:206 msgid "" "The best approach is to use iterators, making it possible to loop through " "objects using the ``for`` statement. For example, :term:`file objects ` support the iterator protocol, so you can write simply::" msgstr "" "La meilleur approche est d'utiliser les itérateurs, rendant possible de " "parcourir des objets en utilisant l'instruction ``for``. Par exemple, les :" "term:`objets fichiers ` gèrent le protocole d'itération, donc " "vous pouvez simplement écrire : ::" #: ../Doc/faq/design.rst:216 msgid "" "Why does Python use methods for some functionality (e.g. list.index()) but " "functions for other (e.g. len(list))?" msgstr "" "Pourquoi Python utilise des méthodes pour certaines fonctionnalités (ex : " "list.index()) mais des fonctions pour d'autres (ex : len(list)) ?" #: ../Doc/faq/design.rst:218 msgid "" "The major reason is history. Functions were used for those operations that " "were generic for a group of types and which were intended to work even for " "objects that didn't have methods at all (e.g. tuples). It is also " "convenient to have a function that can readily be applied to an amorphous " "collection of objects when you use the functional features of Python " "(``map()``, ``zip()`` et al)." msgstr "" "La raison principale est historique. Les fonctions étaient utilisées pour " "ces opérations qui étaient génériques pour un groupe de types et qui étaient " "censés fonctionner même pour les objets qui n'avaient pas de méthodes du " "tout (ex : tuples). C'est aussi pratique d'avoir une fonction qui s'apprête " "bien à une collection amorphe d'objets lorsque vous utiliser les outils " "fonctionnels de Python (``map()``, ``zip()`` et autres)." #: ../Doc/faq/design.rst:224 msgid "" "In fact, implementing ``len()``, ``max()``, ``min()`` as a built-in function " "is actually less code than implementing them as methods for each type. One " "can quibble about individual cases but it's a part of Python, and it's too " "late to make such fundamental changes now. The functions have to remain to " "avoid massive code breakage." msgstr "" "En fait, implémenter ``len()``, ``max()``, ``min()`` en tant que fonction " "intégrée produit moins de code que de les implémenter en tant que méthode " "pour chaque type. Certains peuvent rouspéter pour des cas individuels mais " "ça fait partie de Python et il est trop tard pour faire des changements si " "fondamentaux maintenant. Ces fonctions doivent rester pour éviter la casse " "massive de code." #: ../Doc/faq/design.rst:234 msgid "" "For string operations, Python has moved from external functions (the " "``string`` module) to methods. However, ``len()`` is still a function." msgstr "" "Pour les opérations de chaînes, Python a déplacé les fonctions externes (le " "module ``string``) vers des méthodes. Cependant, ``len()`` est toujours une " "fonction." #: ../Doc/faq/design.rst:239 msgid "Why is join() a string method instead of a list or tuple method?" msgstr "" "Pourquoi join() est une méthode de chaîne plutôt qu'une de liste ou de " "tuple ?" #: ../Doc/faq/design.rst:241 msgid "" "Strings became much more like other standard types starting in Python 1.6, " "when methods were added which give the same functionality that has always " "been available using the functions of the string module. Most of these new " "methods have been widely accepted, but the one which appears to make some " "programmers feel uncomfortable is::" msgstr "" "Les chaînes sont devenues bien plus comme d'autres types standards à partir " "de Python 1.6, lorsque les méthodes ont été ajoutées fournissant ainsi les " "mêmes fonctionnalités que celles qui étaient déjà disponibles en utilisant " "les fonctions du module string. La plupart de ces nouvelles méthodes ont été " "largement acceptées, mais celle qui semble rendre certains programmeurs " "inconfortables est : ::" #: ../Doc/faq/design.rst:249 msgid "which gives the result::" msgstr "qui donne le résultat : ::" #: ../Doc/faq/design.rst:253 msgid "There are two common arguments against this usage." msgstr "Il y a deux arguments fréquents contre cet usage." #: ../Doc/faq/design.rst:255 msgid "" "The first runs along the lines of: \"It looks really ugly using a method of " "a string literal (string constant)\", to which the answer is that it might, " "but a string literal is just a fixed value. If the methods are to be allowed " "on names bound to strings there is no logical reason to make them " "unavailable on literals." msgstr "" "Le premier se caractérise par les lignes suivantes : \"C'est vraiment moche " "d'utiliser une méthode de chaîne littérale (chaîne constante)\", à laquelle " "la réponse est qu'il se peut, mais une chaîne littérale est juste une valeur " "fixe. Si la méthode est autorisée sur des noms liés à des chaînes, il n'y a " "pas de raison logique à les rendre indisponibles sur des chaînes littérales." #: ../Doc/faq/design.rst:261 msgid "" "The second objection is typically cast as: \"I am really telling a sequence " "to join its members together with a string constant\". Sadly, you aren't. " "For some reason there seems to be much less difficulty with having :meth:" "`~str.split` as a string method, since in that case it is easy to see that ::" msgstr "" "La deuxième objection se réfère typiquement à : \"Je suis réellement en " "train de dire à une séquence de joindre ses membres avec une constante de " "chaîne\". Malheureusement, vous ne l'êtes pas. Pour quelque raison, il " "semble être bien moins difficile d'avoir :meth:`~str.split` en tant que " "méthode de chaîne, puisque dans ce cas il est facile de voir que::" #: ../Doc/faq/design.rst:268 msgid "" "is an instruction to a string literal to return the substrings delimited by " "the given separator (or, by default, arbitrary runs of white space)." msgstr "" "est une instruction à une chaîne littérale de renvoyer les sous-chaînes " "délimitées par le séparateur fournit (ou, par défaut, les espaces, ou " "groupes d'espaces)." #: ../Doc/faq/design.rst:271 msgid "" ":meth:`~str.join` is a string method because in using it you are telling the " "separator string to iterate over a sequence of strings and insert itself " "between adjacent elements. This method can be used with any argument which " "obeys the rules for sequence objects, including any new classes you might " "define yourself. Similar methods exist for bytes and bytearray objects." msgstr "" ":meth:`~str.join` est une méthode de chaîne parce qu'en l'utilisant vous " "dites au séparateur de chaîne d'itérer une séquence de chaînes et de " "s'insérer entre les éléments adjacents. Cette méthode peut être utilisée " "avec n'importe quel argument qui obéit aux règles d'objets séquence, " "incluant n'importe quelles nouvelles classes que vous pourriez définir vous-" "même. Des méthodes similaires existent pour des objets bytes et bytearray." #: ../Doc/faq/design.rst:279 msgid "How fast are exceptions?" msgstr "À quel point les exceptions sont-elles rapides ?" #: ../Doc/faq/design.rst:281 msgid "" "A try/except block is extremely efficient if no exceptions are raised. " "Actually catching an exception is expensive. In versions of Python prior to " "2.0 it was common to use this idiom::" msgstr "" "Un bloc try/except est extrêmement efficient tant qu'aucune exception ne " "sont levée. En effet, intercepter une exception s'avère coûteux. Dans les " "versions de précédant Python 2.0, il était courant d'utiliser cette " "pratique ::" #: ../Doc/faq/design.rst:291 msgid "" "This only made sense when you expected the dict to have the key almost all " "the time. If that wasn't the case, you coded it like this::" msgstr "" "Cela n'a de sens que si vous vous attendez à ce que le dictionnaire ait la " "clé presque tout le temps. Si ce n'était pas le cas, vous l'auriez codé " "comme suit : ::" #: ../Doc/faq/design.rst:299 msgid "" "For this specific case, you could also use ``value = dict.setdefault(key, " "getvalue(key))``, but only if the ``getvalue()`` call is cheap enough " "because it is evaluated in all cases." msgstr "" "Pour ce cas, vous pouvez également utiliser ``value = dict.setdefault(key, " "getvalue(key))``, mais seulement si l'appel à ``getvalue()`` est " "suffisamment peu coûteux car il est évalué dans tous les cas." #: ../Doc/faq/design.rst:305 msgid "Why isn't there a switch or case statement in Python?" msgstr "" "Pourquoi n'y a-t-il pas une instruction *switch* ou une structure similaire " "à *switch / case* en Python ?" #: ../Doc/faq/design.rst:307 msgid "" "You can do this easily enough with a sequence of ``if... elif... elif... " "else``. There have been some proposals for switch statement syntax, but " "there is no consensus (yet) on whether and how to do range tests. See :pep:" "`275` for complete details and the current status." msgstr "" "Vous pouvez le faire assez facilement avec une séquence de ``if... elif... " "elif... else``. Il y a eu quelques propositions pour la syntaxe de " "l'instruction switch, mais il n'y a pas (encore) de consensus sur le cas des " "intervalles. Voir la :pep:`275` pour tous les détails et l'état actuel." #: ../Doc/faq/design.rst:312 msgid "" "For cases where you need to choose from a very large number of " "possibilities, you can create a dictionary mapping case values to functions " "to call. For example::" msgstr "" "Dans les cas où vous devez choisir parmi un très grand nombre de " "possibilités, vous pouvez créer un dictionnaire faisant correspondre des " "valeurs à des fonctions à appeler. Par exemple : ::" #: ../Doc/faq/design.rst:326 msgid "" "For calling methods on objects, you can simplify yet further by using the :" "func:`getattr` built-in to retrieve methods with a particular name::" msgstr "" "Pour appeler les méthodes sur des objets, vous pouvez simplifier davantage " "en utilisant la fonction native :func:`getattr` pour récupérer les méthodes " "avec un nom donné : ::" #: ../Doc/faq/design.rst:338 msgid "" "It's suggested that you use a prefix for the method names, such as " "``visit_`` in this example. Without such a prefix, if values are coming " "from an untrusted source, an attacker would be able to call any method on " "your object." msgstr "" "Il est suggéré que vous utilisiez un préfixe pour les noms de méthodes, " "telles que ``visit_`` dans cet exemple. Sans ce préfixe, si les valeurs " "proviennent d'une source non fiable, un attaquant serait en mesure d'appeler " "n'importe quelle méthode sur votre objet." #: ../Doc/faq/design.rst:344 msgid "" "Can't you emulate threads in the interpreter instead of relying on an OS-" "specific thread implementation?" msgstr "" "Est-il possible d'émuler des fils d'exécution dans l'interpréteur plutôt que " "se baser sur les implémentations spécifique aux OS ?" #: ../Doc/faq/design.rst:346 msgid "" "Answer 1: Unfortunately, the interpreter pushes at least one C stack frame " "for each Python stack frame. Also, extensions can call back into Python at " "almost random moments. Therefore, a complete threads implementation " "requires thread support for C." msgstr "" "Réponse 1: Malheureusement, l'interpréteur pousse au moins un block de pile " "C (*stack frame*) pour chaque bloc de pile de Python. Aussi, les extensions " "peuvent rappeler dans Python à presque n'importe quel moment. Par " "conséquent, une implémentation complète des fils d'exécution nécessiterai un " "support complet en C." #: ../Doc/faq/design.rst:351 msgid "" "Answer 2: Fortunately, there is `Stackless Python `_, which has a completely redesigned " "interpreter loop that avoids the C stack." msgstr "" "Réponse 2 : heureusement, il existe `Stackless Python `_, qui à complètement ré-architecturé la " "boucle principale de l'interpréteur afin de ne pas utiliser la pile C." #: ../Doc/faq/design.rst:356 msgid "Why can't lambda expressions contain statements?" msgstr "" "Pourquoi les expressions lambda ne peuvent pas contenir d'instructions ?" #: ../Doc/faq/design.rst:358 msgid "" "Python lambda expressions cannot contain statements because Python's " "syntactic framework can't handle statements nested inside expressions. " "However, in Python, this is not a serious problem. Unlike lambda forms in " "other languages, where they add functionality, Python lambdas are only a " "shorthand notation if you're too lazy to define a function." msgstr "" "Les expressions lambda de Python ne peuvent pas contenir d'instructions " "parce que le cadre syntaxique de Python ne peut pas gérer les instructions " "imbriquées à l'intérieur d'expressions. Cependant, en Python, ce n'est pas " "vraiment un problème. Contrairement aux formes lambda dans d'autres " "langages, où elles ajoutent des fonctionnalités, les expressions lambda de " "Python sont seulement une notation concise si vous êtes trop paresseux pour " "définir une fonction." #: ../Doc/faq/design.rst:364 msgid "" "Functions are already first class objects in Python, and can be declared in " "a local scope. Therefore the only advantage of using a lambda instead of a " "locally-defined function is that you don't need to invent a name for the " "function -- but that's just a local variable to which the function object " "(which is exactly the same type of object that a lambda expression yields) " "is assigned!" msgstr "" "Les fonctions sont déjà des objets de première classe en Python et peuvent " "être déclarées dans une portée locale. L'unique avantage d'utiliser une " "fonction lambda au lieu d'une fonction définie localement est que vous " "n'avez nullement besoin d'un nom pour la fonction -- Mais c'est juste une " "variable locale à laquelle est affecté l'objet fonction (qui est exactement " "le même type d'objet qui donne une expression lambda) !" #: ../Doc/faq/design.rst:372 msgid "Can Python be compiled to machine code, C or some other language?" msgstr "" "Python peut-il être compilé en code machine, en C ou dans un autre langage ?" #: ../Doc/faq/design.rst:374 msgid "" "`Cython `_ compiles a modified version of Python with " "optional annotations into C extensions. `Nuitka `_ " "is an up-and-coming compiler of Python into C++ code, aiming to support the " "full Python language. For compiling to Java you can consider `VOC `_." msgstr "" #: ../Doc/faq/design.rst:382 msgid "How does Python manage memory?" msgstr "Comment Python gère la mémoire ?" #: ../Doc/faq/design.rst:384 msgid "" "The details of Python memory management depend on the implementation. The " "standard implementation of Python, :term:`CPython`, uses reference counting " "to detect inaccessible objects, and another mechanism to collect reference " "cycles, periodically executing a cycle detection algorithm which looks for " "inaccessible cycles and deletes the objects involved. The :mod:`gc` module " "provides functions to perform a garbage collection, obtain debugging " "statistics, and tune the collector's parameters." msgstr "" "Les détails de la gestion de la mémoire en Python dépendent de " "l'implémentation. En effet, l'implémentation standard de Python, :term:" "`CPython`, utilise des compteurs de références afin de détecter des objets " "inaccessibles et un autre mécanisme pour collecter les références " "circulaires, exécutant périodiquement un algorithme de détection de cycles " "qui recherche les cycles inaccessibles et supprime les objets implqués. Le " "module :mod:`gc` fournit des fonctions pour lancer le ramasse-miettes, " "d'obtenir des statistiques de débogage et ajuster ses paramètres." #: ../Doc/faq/design.rst:392 msgid "" "Other implementations (such as `Jython `_ or `PyPy " "`_), however, can rely on a different mechanism such as " "a full-blown garbage collector. This difference can cause some subtle " "porting problems if your Python code depends on the behavior of the " "reference counting implementation." msgstr "" "Cependant, d'autres implémentations (par exemple `Jython `_ ou `PyPy `_) peuvent compter sur un mécanisme " "différent comme un véritable ramasse-miette. Cette différence peut causer de " "subtils problèmes de portabilité si votre code Python dépend du comportement " "de l'implémentation du compteur de références." #: ../Doc/faq/design.rst:398 msgid "" "In some Python implementations, the following code (which is fine in " "CPython) will probably run out of file descriptors::" msgstr "" "Dans certaines implémentations de Python, le code suivant (qui marche " "parfaitement avec *CPython*) aurait probablement manqué de descripteurs de " "fichiers ::" #: ../Doc/faq/design.rst:405 msgid "" "Indeed, using CPython's reference counting and destructor scheme, each new " "assignment to *f* closes the previous file. With a traditional GC, however, " "those file objects will only get collected (and closed) at varying and " "possibly long intervals." msgstr "" "En effet, à l'aide du comptage de références et du destructeur d'objets de " "*CPython*, chaque nouvelle affectation à *f* ferme le fichier précédent. " "Cependant, avec un *GC* classique, ces objets seront seulement recueillies " "(et fermés) à intervalles variables et possiblement avec de longs " "intervalles." #: ../Doc/faq/design.rst:410 msgid "" "If you want to write code that will work with any Python implementation, you " "should explicitly close the file or use the :keyword:`with` statement; this " "will work regardless of memory management scheme::" msgstr "" "Si vous souhaitez écrire du code qui fonctionne avec n'importe quelle " "implémentation de Python, vous devez explicitement fermer le fichier ou " "utiliser l'instruction :keyword:`with` ; ceci fonctionnera indépendamment du " "système de gestion de la mémoire ::" #: ../Doc/faq/design.rst:420 msgid "Why doesn't CPython use a more traditional garbage collection scheme?" msgstr "" "Pourquoi CPython n'utilise-il pas un ramasse-miette plus traditionnel ?" #: ../Doc/faq/design.rst:422 msgid "" "For one thing, this is not a C standard feature and hence it's not portable. " "(Yes, we know about the Boehm GC library. It has bits of assembler code for " "*most* common platforms, not for all of them, and although it is mostly " "transparent, it isn't completely transparent; patches are required to get " "Python to work with it.)" msgstr "" "D'une part, ce n'est pas une caractéristique normalisé en C et par " "conséquent ce n'est pas portable. (Oui, nous connaissons la bibliothèque *GC " "Boehm*. Elle contient du code assembleur pour la plupart des plates-formes " "classiques, mais pas toutes, et bien qu'elle soit le plus souvent " "transparent, c'est loin d'être le cas, des correctifs sont nécessaires afin " "que Python fonctionne correctement avec.)" #: ../Doc/faq/design.rst:428 msgid "" "Traditional GC also becomes a problem when Python is embedded into other " "applications. While in a standalone Python it's fine to replace the " "standard malloc() and free() with versions provided by the GC library, an " "application embedding Python may want to have its *own* substitute for " "malloc() and free(), and may not want Python's. Right now, CPython works " "with anything that implements malloc() and free() properly." msgstr "" "Le *GC* classique devient également un problème lorsque Python est incorporé " "dans d'autres applications. Bien que dans une application Python, il ne soit " "pas gênant de remplacer les fonctions malloc() et free() avec les versions " "fournies par la bibliothèque *GC*, une application incluant Python peut " "vouloir avoir ses propres implémentations de malloc() et free() et peut ne " "pas vouloir celles de Python. À l'heure actuelle, CPython fonctionne avec " "n'importe quelle implémentation correcte de malloc() et free()." #: ../Doc/faq/design.rst:437 msgid "Why isn't all memory freed when CPython exits?" msgstr "" "Pourquoi toute la mémoire n'est pas libérée lorsque *CPython* s'arrête ?" #: ../Doc/faq/design.rst:439 msgid "" "Objects referenced from the global namespaces of Python modules are not " "always deallocated when Python exits. This may happen if there are circular " "references. There are also certain bits of memory that are allocated by the " "C library that are impossible to free (e.g. a tool like Purify will complain " "about these). Python is, however, aggressive about cleaning up memory on " "exit and does try to destroy every single object." msgstr "" "Les objets référencés depuis les espaces de noms globaux des modules Python " "ne sont pas toujours désalloués lorsque Python s'arrête. Cela peut se " "produire s'il y a des références circulaires. Il y a aussi certaines parties " "de mémoire qui sont alloués par la bibliothèque C qui sont impossibles à " "libérer (par exemple un outil comme *Purify* s'en plaindra). Python est, " "cependant, agressif sur le nettoyage de la mémoire en quittant et cherche à " "détruire chaque objet." #: ../Doc/faq/design.rst:446 msgid "" "If you want to force Python to delete certain things on deallocation use " "the :mod:`atexit` module to run a function that will force those deletions." msgstr "" "Si vous voulez forcer Python à désallouer certains objets en quittant, " "utilisez le module :mod:`texit` pour exécuter une fonction qui va forcer ces " "destructions." #: ../Doc/faq/design.rst:451 msgid "Why are there separate tuple and list data types?" msgstr "" "Pourquoi les *tuples* et les *list* sont deux types de données séparés ?" #: ../Doc/faq/design.rst:453 msgid "" "Lists and tuples, while similar in many respects, are generally used in " "fundamentally different ways. Tuples can be thought of as being similar to " "Pascal records or C structs; they're small collections of related data which " "may be of different types which are operated on as a group. For example, a " "Cartesian coordinate is appropriately represented as a tuple of two or three " "numbers." msgstr "" "Les listes et les *tuples*, bien que semblable à bien des égards, sont " "généralement utilisés de façons fondamentalement différentes. Les *tuples* " "peuvent être considérés comme étant similaires aux dossiers en Pascal ou aux " "structures en C; Ce sont de petites collections de données associées qui " "peuvent être de différents types qui sont utilisées sensemble. Par exemple, " "un repère cartésien est correctement représenté comme un *tuple* de deux ou " "trois nombres." #: ../Doc/faq/design.rst:460 msgid "" "Lists, on the other hand, are more like arrays in other languages. They " "tend to hold a varying number of objects all of which have the same type and " "which are operated on one-by-one. For example, ``os.listdir('.')`` returns " "a list of strings representing the files in the current directory. " "Functions which operate on this output would generally not break if you " "added another file or two to the directory." msgstr "" "Les listes, ressemblent davantage à des tableaux dans d'autres langues. " "Elles ont tendance à contenir un nombre variable d'objets de même type " "manipulés individuellement. Par exemple, ``os.listdir('.')`` renvoie une " "liste de chaînes représentant les fichiers dans le dossier courant. Les " "fonctions travaillant sur cette sortie accepteraient généralement sans aucun " "problème que vous ajoutiez un ou deux fichiers supplémentaire dans le " "dossier." #: ../Doc/faq/design.rst:467 msgid "" "Tuples are immutable, meaning that once a tuple has been created, you can't " "replace any of its elements with a new value. Lists are mutable, meaning " "that you can always change a list's elements. Only immutable elements can " "be used as dictionary keys, and hence only tuples and not lists can be used " "as keys." msgstr "" "Les *tuples* sont immuables, ce qui signifie que lorsqu'un *tuple* a été " "créé, vous ne pouvez remplacer aucun de ses éléments par une nouvelle " "valeur. Les listes sont muables, ce qui signifie que vous pouvez toujours " "modifier les éléments d'une liste. Seuls des éléments immuables peuvent être " "utilisés comme clés de dictionnaires, et donc de ``tuple`` et ``list`` seul " "des *tuples* peuvent être utilisés comme clés." #: ../Doc/faq/design.rst:474 msgid "How are lists implemented?" msgstr "Comment est-ce que les listes sont implémentées ?" #: ../Doc/faq/design.rst:476 msgid "" "Python's lists are really variable-length arrays, not Lisp-style linked " "lists. The implementation uses a contiguous array of references to other " "objects, and keeps a pointer to this array and the array's length in a list " "head structure." msgstr "" "Les listes en Python sont de vrais tableaux de longueur variable " "contrairement à des listes orientées *Lisp* (i.e des listes chaînées). " "L'implémentation utilise un tableau contigu de références à d'autres objets. " "Elle conserve également un pointeur vers ce tableau et la longueur du " "tableau dans une structure de tête de liste." #: ../Doc/faq/design.rst:480 msgid "" "This makes indexing a list ``a[i]`` an operation whose cost is independent " "of the size of the list or the value of the index." msgstr "" "Cela rend l'indexation d'une liste ``a[i]`` une opération dont le coût est " "indépendant de la taille de la liste ou de la valeur de l'indice." #: ../Doc/faq/design.rst:483 msgid "" "When items are appended or inserted, the array of references is resized. " "Some cleverness is applied to improve the performance of appending items " "repeatedly; when the array must be grown, some extra space is allocated so " "the next few times don't require an actual resize." msgstr "" "Lorsque des éléments sont ajoutés ou insérés, le tableau de références est " "redimensionné. Un savoir-faire ingénieux permet l'amélioration des " "performances lors de l'ajout fréquent d'éléments ; Lorsque le tableau doit " "être étendu, un certain espace supplémentaire est alloué de sorte que pour " "la prochaine fois, ceci ne nécessite plus un redimensionnement effectif." #: ../Doc/faq/design.rst:490 msgid "How are dictionaries implemented?" msgstr "Comment les dictionnaires sont-ils implémentés ?" #: ../Doc/faq/design.rst:492 msgid "" "Python's dictionaries are implemented as resizable hash tables. Compared to " "B-trees, this gives better performance for lookup (the most common operation " "by far) under most circumstances, and the implementation is simpler." msgstr "" "Les dictionnaires Python sont implémentés sous forme de tables de hachage " "redimensionnables. Par rapport aux *B-trees*, cela donne de meilleures " "performances pour la recherche (l'opération la plus courante de loin) dans " "la plupart des circonstances, et leur implémentation est plus simple." #: ../Doc/faq/design.rst:496 msgid "" "Dictionaries work by computing a hash code for each key stored in the " "dictionary using the :func:`hash` built-in function. The hash code varies " "widely depending on the key and a per-process seed; for example, \"Python\" " "could hash to -539294296 while \"python\", a string that differs by a single " "bit, could hash to 1142331976. The hash code is then used to calculate a " "location in an internal array where the value will be stored. Assuming that " "you're storing keys that all have different hash values, this means that " "dictionaries take constant time -- O(1), in Big-O notation -- to retrieve a " "key." msgstr "" "Les dictionnaires fonctionnent en calculant un code de hachage pour chaque " "clé stockée dans le dictionnaire en utilisant la fonction :func:`hash`. Le " "code de hachage varie grandement selon la clé et du nombre de processus " "utilisés ; Par exemple, la chaine de caractère \"Python\" pourrait avoir " "comme code de hachage une valeur allant jusqu'à-539294296 tandis que la " "chaine \"python\",qui se distingue de la première par un seul bit, pourrait " "avoir comme code de hachage une valeur allant jusqu'à 1142331976. Le code " "de hachage est ensuite utilisé pour calculer un emplacement dans un tableau " "interne où la valeur est stockée. Dans l'hypothèse où vous stockez les clés " "qui ont toutes des valeurs de hachage différentes, cela signifie que les " "dictionnaires parcourt le dictionnaire en un temps constant -- O(1), en " "notation grand O de Landau - - pour récupérer une clé." #: ../Doc/faq/design.rst:507 msgid "Why must dictionary keys be immutable?" msgstr "Pourquoi les clés du dictionnaire sont immuables ?" #: ../Doc/faq/design.rst:509 msgid "" "The hash table implementation of dictionaries uses a hash value calculated " "from the key value to find the key. If the key were a mutable object, its " "value could change, and thus its hash could also change. But since whoever " "changes the key object can't tell that it was being used as a dictionary " "key, it can't move the entry around in the dictionary. Then, when you try " "to look up the same object in the dictionary it won't be found because its " "hash value is different. If you tried to look up the old value it wouldn't " "be found either, because the value of the object found in that hash bin " "would be different." msgstr "" "L'implémentation de la table de hachage des dictionnaires utilise une valeur " "de hachage calculée à partir de la valeur de la clé pour trouver la clé elle-" "même. Si la clé était un objet muable, sa valeur peut changer, et donc son " "hachage pourrait également changer. Mais toute personne modifiant l'objet " "clé ne peut pas dire qu'elle a été utilisée comme une clé de dictionnaire. " "Il ne peut déplacer l'entrée dans le dictionnaire. Ainsi, lorsque vous " "essayez de rechercher le même objet dans le dictionnaire, il ne sera pas " "disponible parce que sa valeur de hachage est différente. Si vous essayez de " "chercher l'ancienne valeur, elle serait également introuvable car la valeur " "de l'objet trouvé dans cet emplacement de hachage serait différente." #: ../Doc/faq/design.rst:518 msgid "" "If you want a dictionary indexed with a list, simply convert the list to a " "tuple first; the function ``tuple(L)`` creates a tuple with the same entries " "as the list ``L``. Tuples are immutable and can therefore be used as " "dictionary keys." msgstr "" "Si vous voulez un dictionnaire indexé avec une liste, il faut simplement " "convertir la liste en un *tuple* ; la fonction ``tuple(L)`` crée un " "*tuple* avec les mêmes entrées que la liste ``L``. Les *tuples* sont " "immuables et peuvent donc être utilisés comme clés du dictionnaire." #: ../Doc/faq/design.rst:522 msgid "Some unacceptable solutions that have been proposed:" msgstr "Certaines solutions insatisfaisantes qui ont été proposées :" #: ../Doc/faq/design.rst:524 msgid "" "Hash lists by their address (object ID). This doesn't work because if you " "construct a new list with the same value it won't be found; e.g.::" msgstr "" "Les listes de hachage par leur adresse (*ID* de l'objet). Cela ne " "fonctionne pas parce que si vous créez une nouvelle liste avec la même " "valeur, elle ne sera pas retrouvée; par exemple ::" #: ../Doc/faq/design.rst:530 msgid "" "would raise a KeyError exception because the id of the ``[1, 2]`` used in " "the second line differs from that in the first line. In other words, " "dictionary keys should be compared using ``==``, not using :keyword:`is`." msgstr "" "cela soulèverait une exception de type *KeyError* car l'id de ``[1, 2]`` " "utilisée dans la deuxième ligne diffère de celle de la première ligne. En " "d'autres termes, les clés de dictionnaire doivent être comparées à l'aide du " "comparateur ``==`` et non à l'aide du :keyword:`is`." #: ../Doc/faq/design.rst:534 msgid "" "Make a copy when using a list as a key. This doesn't work because the list, " "being a mutable object, could contain a reference to itself, and then the " "copying code would run into an infinite loop." msgstr "" "Faire une copie lors de l'utilisation d'une liste en tant que clé. Cela ne " "fonctionne pas puisque la liste, étant un objet muable, pourrait contenir " "une référence à elle-même ou avoir une boucle infinie au niveau du code " "copié." #: ../Doc/faq/design.rst:538 msgid "" "Allow lists as keys but tell the user not to modify them. This would allow " "a class of hard-to-track bugs in programs when you forgot or modified a list " "by accident. It also invalidates an important invariant of dictionaries: " "every value in ``d.keys()`` is usable as a key of the dictionary." msgstr "" #: ../Doc/faq/design.rst:543 msgid "" "Mark lists as read-only once they are used as a dictionary key. The problem " "is that it's not just the top-level object that could change its value; you " "could use a tuple containing a list as a key. Entering anything as a key " "into a dictionary would require marking all objects reachable from there as " "read-only -- and again, self-referential objects could cause an infinite " "loop." msgstr "" #: ../Doc/faq/design.rst:549 msgid "" "There is a trick to get around this if you need to, but use it at your own " "risk: You can wrap a mutable structure inside a class instance which has " "both a :meth:`__eq__` and a :meth:`__hash__` method. You must then make " "sure that the hash value for all such wrapper objects that reside in a " "dictionary (or other hash based structure), remain fixed while the object is " "in the dictionary (or other structure). ::" msgstr "" #: ../Doc/faq/design.rst:573 msgid "" "Note that the hash computation is complicated by the possibility that some " "members of the list may be unhashable and also by the possibility of " "arithmetic overflow." msgstr "" #: ../Doc/faq/design.rst:577 msgid "" "Furthermore it must always be the case that if ``o1 == o2`` (ie ``o1." "__eq__(o2) is True``) then ``hash(o1) == hash(o2)`` (ie, ``o1.__hash__() == " "o2.__hash__()``), regardless of whether the object is in a dictionary or " "not. If you fail to meet these restrictions dictionaries and other hash " "based structures will misbehave." msgstr "" #: ../Doc/faq/design.rst:582 msgid "" "In the case of ListWrapper, whenever the wrapper object is in a dictionary " "the wrapped list must not change to avoid anomalies. Don't do this unless " "you are prepared to think hard about the requirements and the consequences " "of not meeting them correctly. Consider yourself warned." msgstr "" #: ../Doc/faq/design.rst:589 msgid "Why doesn't list.sort() return the sorted list?" msgstr "" #: ../Doc/faq/design.rst:591 msgid "" "In situations where performance matters, making a copy of the list just to " "sort it would be wasteful. Therefore, :meth:`list.sort` sorts the list in " "place. In order to remind you of that fact, it does not return the sorted " "list. This way, you won't be fooled into accidentally overwriting a list " "when you need a sorted copy but also need to keep the unsorted version " "around." msgstr "" #: ../Doc/faq/design.rst:597 msgid "" "If you want to return a new list, use the built-in :func:`sorted` function " "instead. This function creates a new list from a provided iterable, sorts " "it and returns it. For example, here's how to iterate over the keys of a " "dictionary in sorted order::" msgstr "" #: ../Doc/faq/design.rst:607 msgid "How do you specify and enforce an interface spec in Python?" msgstr "" #: ../Doc/faq/design.rst:609 msgid "" "An interface specification for a module as provided by languages such as C++ " "and Java describes the prototypes for the methods and functions of the " "module. Many feel that compile-time enforcement of interface specifications " "helps in the construction of large programs." msgstr "" #: ../Doc/faq/design.rst:614 msgid "" "Python 2.6 adds an :mod:`abc` module that lets you define Abstract Base " "Classes (ABCs). You can then use :func:`isinstance` and :func:`issubclass` " "to check whether an instance or a class implements a particular ABC. The :" "mod:`collections.abc` module defines a set of useful ABCs such as :class:" "`~collections.abc.Iterable`, :class:`~collections.abc.Container`, and :class:" "`~collections.abc.MutableMapping`." msgstr "" #: ../Doc/faq/design.rst:621 msgid "" "For Python, many of the advantages of interface specifications can be " "obtained by an appropriate test discipline for components. There is also a " "tool, PyChecker, which can be used to find problems due to subclassing." msgstr "" #: ../Doc/faq/design.rst:625 msgid "" "A good test suite for a module can both provide a regression test and serve " "as a module interface specification and a set of examples. Many Python " "modules can be run as a script to provide a simple \"self test.\" Even " "modules which use complex external interfaces can often be tested in " "isolation using trivial \"stub\" emulations of the external interface. The :" "mod:`doctest` and :mod:`unittest` modules or third-party test frameworks can " "be used to construct exhaustive test suites that exercise every line of code " "in a module." msgstr "" #: ../Doc/faq/design.rst:633 msgid "" "An appropriate testing discipline can help build large complex applications " "in Python as well as having interface specifications would. In fact, it can " "be better because an interface specification cannot test certain properties " "of a program. For example, the :meth:`append` method is expected to add new " "elements to the end of some internal list; an interface specification cannot " "test that your :meth:`append` implementation will actually do this " "correctly, but it's trivial to check this property in a test suite." msgstr "" #: ../Doc/faq/design.rst:641 msgid "" "Writing test suites is very helpful, and you might want to design your code " "with an eye to making it easily tested. One increasingly popular technique, " "test-directed development, calls for writing parts of the test suite first, " "before you write any of the actual code. Of course Python allows you to be " "sloppy and not write test cases at all." msgstr "" #: ../Doc/faq/design.rst:649 msgid "Why is there no goto?" msgstr "Pourquoi n'y a-t-il pas de goto en Python ?" #: ../Doc/faq/design.rst:651 msgid "" "You can use exceptions to provide a \"structured goto\" that even works " "across function calls. Many feel that exceptions can conveniently emulate " "all reasonable uses of the \"go\" or \"goto\" constructs of C, Fortran, and " "other languages. For example::" msgstr "" "Vous pouvez utiliser les exceptions afin de mettre en place un \"goto " "structuré\" qui fonctionne même avec les appels de fonctions. Beaucoup de " "personnes estiment que les exceptions peuvent émuler idéalement tout " "utilisation raisonnable des constructions \"go\" ou \"goto\" en C, en " "Fortran ou autres langages de programmation. Par exemple ::" #: ../Doc/faq/design.rst:666 msgid "" "This doesn't allow you to jump into the middle of a loop, but that's usually " "considered an abuse of goto anyway. Use sparingly." msgstr "" "Cela ne vous permet pas de sauter au milieu d'une boucle. Néanmoins, dans " "tous les cas cela est généralement considéré comme un abus de goto. À " "Utiliser avec parcimonie." #: ../Doc/faq/design.rst:671 msgid "Why can't raw strings (r-strings) end with a backslash?" msgstr "" #: ../Doc/faq/design.rst:673 msgid "" "More precisely, they can't end with an odd number of backslashes: the " "unpaired backslash at the end escapes the closing quote character, leaving " "an unterminated string." msgstr "" #: ../Doc/faq/design.rst:677 msgid "" "Raw strings were designed to ease creating input for processors (chiefly " "regular expression engines) that want to do their own backslash escape " "processing. Such processors consider an unmatched trailing backslash to be " "an error anyway, so raw strings disallow that. In return, they allow you to " "pass on the string quote character by escaping it with a backslash. These " "rules work well when r-strings are used for their intended purpose." msgstr "" #: ../Doc/faq/design.rst:684 msgid "" "If you're trying to build Windows pathnames, note that all Windows system " "calls accept forward slashes too::" msgstr "" #: ../Doc/faq/design.rst:689 msgid "" "If you're trying to build a pathname for a DOS command, try e.g. one of ::" msgstr "" #: ../Doc/faq/design.rst:697 msgid "Why doesn't Python have a \"with\" statement for attribute assignments?" msgstr "" "Pourquoi la déclaration \"with\" pour les assignations d'attributs n'existe " "pas en Python ?" #: ../Doc/faq/design.rst:699 msgid "" "Python has a 'with' statement that wraps the execution of a block, calling " "code on the entrance and exit from the block. Some language have a " "construct that looks like this::" msgstr "" "Python a une instruction \"with\" qui encapsule l'exécution d'un bloc, en " "appelant le code sur l'entrée et la sortie du bloc. Certains langages " "possèdent une construction qui ressemble à ceci ::" #: ../Doc/faq/design.rst:707 msgid "In Python, such a construct would be ambiguous." msgstr "En Python, une telle construction serait ambiguë." #: ../Doc/faq/design.rst:709 msgid "" "Other languages, such as Object Pascal, Delphi, and C++, use static types, " "so it's possible to know, in an unambiguous way, what member is being " "assigned to. This is the main point of static typing -- the compiler " "*always* knows the scope of every variable at compile time." msgstr "" "Les autres langages, tels que le Pascal, le Delphi et le C++ utilisent des " "types statiques, il est donc possible de savoir d'une manière claire et " "directe ce à quoi est attribué un membre. C'est le point principal du typage " "statique --le compilateur connaît *toujours* la portée de toutes les " "variables au moment de la compilation." #: ../Doc/faq/design.rst:714 msgid "" "Python uses dynamic types. It is impossible to know in advance which " "attribute will be referenced at runtime. Member attributes may be added or " "removed from objects on the fly. This makes it impossible to know, from a " "simple reading, what attribute is being referenced: a local one, a global " "one, or a member attribute?" msgstr "" "Python utilise le typage dynamique. Il est impossible de savoir à l'avance " "quel attribut est utilisé comme référence lors de l'exécution. Les attributs " "membres peuvent être ajoutés ou retirés des objets à la volée. Il est donc " "impossible de savoir, d'une simple lecture, quel attribut est référencé : " "s'il est local, global ou un attribut membre?" #: ../Doc/faq/design.rst:720 msgid "For instance, take the following incomplete snippet::" msgstr "" #: ../Doc/faq/design.rst:726 msgid "" "The snippet assumes that \"a\" must have a member attribute called \"x\". " "However, there is nothing in Python that tells the interpreter this. What " "should happen if \"a\" is, let us say, an integer? If there is a global " "variable named \"x\", will it be used inside the with block? As you see, " "the dynamic nature of Python makes such choices much harder." msgstr "" #: ../Doc/faq/design.rst:732 msgid "" "The primary benefit of \"with\" and similar language features (reduction of " "code volume) can, however, easily be achieved in Python by assignment. " "Instead of::" msgstr "" #: ../Doc/faq/design.rst:739 msgid "write this::" msgstr "" #: ../Doc/faq/design.rst:746 msgid "" "This also has the side-effect of increasing execution speed because name " "bindings are resolved at run-time in Python, and the second version only " "needs to perform the resolution once." msgstr "" #: ../Doc/faq/design.rst:752 msgid "Why are colons required for the if/while/def/class statements?" msgstr "" #: ../Doc/faq/design.rst:754 msgid "" "The colon is required primarily to enhance readability (one of the results " "of the experimental ABC language). Consider this::" msgstr "" #: ../Doc/faq/design.rst:760 msgid "versus ::" msgstr "" #: ../Doc/faq/design.rst:765 msgid "" "Notice how the second one is slightly easier to read. Notice further how a " "colon sets off the example in this FAQ answer; it's a standard usage in " "English." msgstr "" #: ../Doc/faq/design.rst:768 msgid "" "Another minor reason is that the colon makes it easier for editors with " "syntax highlighting; they can look for colons to decide when indentation " "needs to be increased instead of having to do a more elaborate parsing of " "the program text." msgstr "" #: ../Doc/faq/design.rst:774 msgid "Why does Python allow commas at the end of lists and tuples?" msgstr "" #: ../Doc/faq/design.rst:776 msgid "" "Python lets you add a trailing comma at the end of lists, tuples, and " "dictionaries::" msgstr "" #: ../Doc/faq/design.rst:787 msgid "There are several reasons to allow this." msgstr "Il y a plusieurs raisons d'accepter cela." #: ../Doc/faq/design.rst:789 msgid "" "When you have a literal value for a list, tuple, or dictionary spread across " "multiple lines, it's easier to add more elements because you don't have to " "remember to add a comma to the previous line. The lines can also be " "reordered without creating a syntax error." msgstr "" #: ../Doc/faq/design.rst:794 msgid "" "Accidentally omitting the comma can lead to errors that are hard to " "diagnose. For example::" msgstr "" #: ../Doc/faq/design.rst:804 msgid "" "This list looks like it has four elements, but it actually contains three: " "\"fee\", \"fiefoo\" and \"fum\". Always adding the comma avoids this source " "of error." msgstr "" #: ../Doc/faq/design.rst:807 msgid "" "Allowing the trailing comma may also make programmatic code generation " "easier." msgstr "" #~ msgid "Practical answer:" #~ msgstr "Réponse concrète :" #~ msgid "Theoretical answer:" #~ msgstr "Réponse théorique :" #~ msgid "" #~ "Not trivially. Python's high level data types, dynamic typing of objects " #~ "and run-time invocation of the interpreter (using :func:`eval` or :func:" #~ "`exec`) together mean that a naïvely \"compiled\" Python program would " #~ "probably consist mostly of calls into the Python run-time system, even " #~ "for seemingly simple operations like ``x+1``." #~ msgstr "" #~ "Pas de façon triviale. Les types de données haut niveau de Python, le " #~ "typage dynamique des objets et l'invocation de l’interpréteur à " #~ "l'exécution (via :func:`eval` ou :func:`exec`) font qu'un programme " #~ "Python compilé naïvement consisterait probablement principalement à faire " #~ "des appels au système d'exécution de Python, même pour des opérations " #~ "simples comme ``x + 1``." #~ msgid "" #~ "Several projects described in the Python newsgroup or at past `Python " #~ "conferences `_ have shown " #~ "that this approach is feasible, although the speedups reached so far are " #~ "only modest (e.g. 2x). Jython uses the same strategy for compiling to " #~ "Java bytecode. (Jim Hugunin has demonstrated that in combination with " #~ "whole-program analysis, speedups of 1000x are feasible for small demo " #~ "programs. See the proceedings from the `1997 Python conference `_ for more information.)" #~ msgstr "" #~ "Plusieurs projets décrits dans le forum de Python ou dans les anciennes " #~ "`Conférences Python `_ ont " #~ "montré que cette approche est réalisable, même si les améliorations " #~ "atteintes restaient modestes (autour de ×2). Jython utilise la même " #~ "stratégie pour compiler en *bytecode* Java. (Jim Hugunin a démontré qu'en " #~ "combinaison avec une analyse de la totalité du programme, des " #~ "améliorations de ×1000 sont possibles sur de petits programmes de " #~ "démonstration. Voir le compte rendu de la `Conférence de Python 1997 " #~ "`_ pour plus " #~ "d'informations.)"