# SOME DESCRIPTIVE TITLE. # Copyright (C) 1990-2016, Python Software Foundation # This file is distributed under the same license as the Python package. # FIRST AUTHOR , YEAR. # #, fuzzy msgid "" msgstr "" "Project-Id-Version: Python 2.7\n" "Report-Msgid-Bugs-To: \n" "POT-Creation-Date: 2016-10-30 10:44+0100\n" "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" "Last-Translator: FULL NAME \n" "Language-Team: LANGUAGE \n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" #: ../Doc/faq/design.rst:3 msgid "Design and History FAQ" msgstr "FAQ histoire et design" #: ../Doc/faq/design.rst:6 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:8 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 clarté globale " "du programme Python. La plupart des gens finissent par aimer cette " "particularité au bout d'un moment." #: ../Doc/faq/design.rst:12 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:21 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:26 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:31 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 placent les accolades de début/fin sur une " "ligne à part. Cela rend les sources beaucoup plus longues 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 les types de haut-niveau en " "sont également responsables -- mais la syntaxe basée sur l'indentation y est " "pour beaucoup." #: ../Doc/faq/design.rst:41 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:43 msgid "See the next question." msgstr "Voir la question suivante." #: ../Doc/faq/design.rst:47 msgid "Why are floating point calculations so inaccurate?" msgstr "Pourquoi les calculs à virgules flottantes sont si imprécis ?" #: ../Doc/faq/design.rst:49 msgid "People are often very surprised by results like this::" msgstr "" "Les gens sont très souvent surpris par des résultats comme celui-ci : ::" #: ../Doc/faq/design.rst:54 msgid "" "and think it is a bug in Python. It's not. This has nothing to do with " "Python, but with how the underlying C platform handles floating point " "numbers, and ultimately with the inaccuracies introduced when writing down " "numbers as a string of a fixed number of digits." msgstr "" "et pensent que c'est un bogue dans Python. Ça ne l'est pas. Ceci n'a rien à " "voir avec Python, mais avec la manière dont la plateforme C sous-jacente " "gère les nombres à virgule flottante et enfin, les imprécisions introduites " "lors de l'écriture des nombres en chaînes de caractères d'un nombre fixe de " "chiffres." #: ../Doc/faq/design.rst:59 msgid "" "The internal representation of floating point numbers uses a fixed number of " "binary digits to represent a decimal number. Some decimal numbers can't be " "represented exactly in binary, resulting in small roundoff errors." msgstr "" "La représentation interne des nombres à virgule flottante utilise un nombre " "fixe de chiffres binaires pour représenter un nombre décimal. Certains " "nombres décimaux ne peuvent être représentés exactement en binaire, " "résultant ainsi à de petites erreurs d'arrondi." #: ../Doc/faq/design.rst:63 msgid "" "In decimal math, there are many numbers that can't be represented with a " "fixed number of decimal digits, e.g. 1/3 = 0.3333333333......." msgstr "" "En mathématiques, beaucoup de nombre ne peuvent être représentés par un " "nombre fixe de chiffres, par exemple 1/3 = 0.3333333333......." #: ../Doc/faq/design.rst:66 msgid "" "In base 2, 1/2 = 0.1, 1/4 = 0.01, 1/8 = 0.001, etc. .2 equals 2/10 equals " "1/5, resulting in the binary fractional number 0.001100110011001..." msgstr "" "En base 2, 1/2 = 0.1, 1/4 = 0.01, 1/8 = 0.001, etc. .2 est égale à 2/10 qui " "est égale à 1/5, ayant pour résultat le nombre fractionnel binaire " "0.001100110011001..." #: ../Doc/faq/design.rst:69 msgid "" "Floating point numbers only have 32 or 64 bits of precision, so the digits " "are cut off at some point, and the resulting number is 0.199999999999999996 " "in decimal, not 0.2." msgstr "" "Les nombres à virgule flottante ont une précision de seulement 32 ou 64 " "bits, donc les chiffres finissent par être tronqués, et le nombre résultant " "est 0.199999999999999996 en décimal, pas 0.2." #: ../Doc/faq/design.rst:73 msgid "" "A floating point number's ``repr()`` function prints as many digits are " "necessary to make ``eval(repr(f)) == f`` true for any float f. The " "``str()`` function prints fewer digits and this often results in the more " "sensible number that was probably intended::" msgstr "" "La fonction ``repr()`` d'un nombre décimal affiche autant de chiffres que " "nécessaire pour rendre l'expression ``eval(repr(f)) == f`` vraie pour tout " "nombre décimal f. La fonction ``str()`` affiche moins de chiffres et " "correspond généralement plus au nombre attendu ::" #: ../Doc/faq/design.rst:83 msgid "" "One of the consequences of this is that it is error-prone to compare the " "result of some computation to a float with ``==``. Tiny inaccuracies may " "mean that ``==`` fails. Instead, you have to check that the difference " "between the two numbers is less than a certain threshold::" msgstr "" "En conséquence comparer le résultat d'un calcul avec un nombre flottant " "avec l'opérateur '==' est propice à l'obtention d'erreurs. D'infimes " "imprécisions peuvent faire qu'un test d'égalité avec \"==\" échoue. Au lieu " "de cela, vous devez vérifier que la différence entre les deux chiffres est " "inférieure à un certain seuil ::" #: ../Doc/faq/design.rst:94 msgid "" "Please see the chapter on :ref:`floating point arithmetic ` " "in the Python tutorial for more information." 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:99 msgid "Why are Python strings immutable?" msgstr "Pourquoi les chaînes de caractères Python sont-elles immuables ?" #: ../Doc/faq/design.rst:101 msgid "There are several advantages." msgstr "Il y a plusieurs avantages." #: ../Doc/faq/design.rst:103 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:108 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:116 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:118 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:121 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 ambiguïté 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:131 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:140 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:156 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:158 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:166 msgid "where in Python you're forced to write this::" msgstr "où en Python vous êtes forcé à écrire ceci : ::" #: ../Doc/faq/design.rst:174 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:186 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:189 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 économisaient " "quelques touches mais utilisaient des mots clefs ou des syntaxes arbitraires " "ou cryptiques, et manquaient à la règle que toute proposition de changement " "de langage devrait respecter : elle doit intuitivement suggérer la bonne " "signification au lecteur qui n'a pas encore été introduit à cette syntaxe." #: ../Doc/faq/design.rst:194 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:199 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:207 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:212 msgid "" "The best approach is to use iterators, making it possible to loop through " "objects using the ``for`` statement. For example, in the current version of " "Python file objects support the iterator protocol, so you can now write " "simply::" msgstr "" "La meilleur approche est d'utiliser les itérateurs, rendant possible de " "boucler au travers d'objets en utilisant la déclaration ``for``. Par " "exemple, dans la version actuelle de Python, les fichiers objets supportent " "le protocole d'itérateur, vous pouvez alors simplement écrire : ::" #: ../Doc/faq/design.rst:222 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:224 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:230 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:240 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:245 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:247 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:255 msgid "which gives the result::" msgstr "qui donne le résultat : ::" #: ../Doc/faq/design.rst:259 msgid "There are two common arguments against this usage." msgstr "Il y a deux arguments fréquents contre cet usage." #: ../Doc/faq/design.rst:261 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:267 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:274 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). In " "this case a Unicode string returns a list of Unicode strings, an ASCII " "string returns a list of ASCII strings, and everyone is happy." msgstr "" #: ../Doc/faq/design.rst:279 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." msgstr "" #: ../Doc/faq/design.rst:284 msgid "" "Because this is a string method it can work for Unicode strings as well as " "plain ASCII strings. If ``join()`` were a method of the sequence types then " "the sequence types would have to decide which type of string to return " "depending on the type of the separator." msgstr "" #: ../Doc/faq/design.rst:291 msgid "" "If none of these arguments persuade you, then for the moment you can " "continue to use the ``join()`` function from the string module, which allows " "you to write ::" msgstr "" #: ../Doc/faq/design.rst:298 msgid "How fast are exceptions?" msgstr "À quel point les exceptions sont-elles rapides ?" #: ../Doc/faq/design.rst:300 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:310 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:320 msgid "" "In Python 2.0 and higher, you can code this as ``value = mydict." "setdefault(key, getvalue(key))``." msgstr "" #: ../Doc/faq/design.rst:325 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:327 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:332 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:346 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:358 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:364 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:366 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 bloc 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:371 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:376 msgid "Why can't lambda expressions contain statements?" msgstr "" "Pourquoi les expressions lambda ne peuvent pas contenir d'instructions ?" #: ../Doc/faq/design.rst:378 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:384 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:392 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:394 msgid "" "Not easily. Python's high level data types, dynamic typing of objects and " "run-time invocation of the interpreter (using :func:`eval` or :keyword:" "`exec`) together mean that a \"compiled\" Python program would probably " "consist mostly of calls into the Python run-time system, even for seemingly " "simple operations like ``x+1``." msgstr "" #: ../Doc/faq/design.rst:400 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.)" #: ../Doc/faq/design.rst:409 msgid "" "Internally, Python source code is always translated into a bytecode " "representation, and this bytecode is then executed by the Python virtual " "machine. In order to avoid the overhead of repeatedly parsing and " "translating modules that rarely change, this byte code is written into a " "file whose name ends in \".pyc\" whenever a module is parsed. When the " "corresponding .py file is changed, it is parsed and translated again and " "the .pyc file is rewritten." msgstr "" #: ../Doc/faq/design.rst:416 msgid "" "There is no performance difference once the .pyc file has been loaded, as " "the bytecode read from the .pyc file is exactly the same as the bytecode " "created by direct translation. The only difference is that loading code " "from a .pyc file is faster than parsing and translating a .py file, so the " "presence of precompiled .pyc files improves the start-up time of Python " "scripts. If desired, the Lib/compileall.py module can be used to create " "valid .pyc files for a given set of modules." msgstr "" #: ../Doc/faq/design.rst:424 msgid "" "Note that the main script executed by Python, even if its filename ends in ." "py, is not compiled to a .pyc file. It is compiled to bytecode, but the " "bytecode is not saved to a file. Usually main scripts are quite short, so " "this doesn't cost much speed." msgstr "" #: ../Doc/faq/design.rst:431 msgid "" "There are also several programs which make it easier to intermingle Python " "and C code in various ways to increase performance. See, for example, " "`Cython `_ , `Psyco `_, " "`Pyrex `_, `PyInline " "`_, `Py2Cmod `_, and `Weave `_." msgstr "" #: ../Doc/faq/design.rst:441 msgid "How does Python manage memory?" msgstr "Comment Python gère la mémoire ?" #: ../Doc/faq/design.rst:443 msgid "" "The details of Python memory management depend on the implementation. The " "standard C implementation of Python 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 "" #: ../Doc/faq/design.rst:451 msgid "" "Jython relies on the Java runtime so the JVM's garbage collector is used. " "This difference can cause some subtle porting problems if your Python code " "depends on the behavior of the reference counting implementation." msgstr "" #: ../Doc/faq/design.rst:457 msgid "" "Sometimes objects get stuck in tracebacks temporarily and hence are not " "deallocated when you might expect. Clear the tracebacks with::" msgstr "" #: ../Doc/faq/design.rst:464 msgid "" "Tracebacks are used for reporting errors, implementing debuggers and related " "things. They contain a portion of the program state extracted during the " "handling of an exception (usually the most recent exception)." msgstr "" #: ../Doc/faq/design.rst:468 msgid "" "In the absence of circularities and tracebacks, Python programs do not need " "to manage memory explicitly." msgstr "" #: ../Doc/faq/design.rst:471 msgid "" "Why doesn't Python use a more traditional garbage collection scheme? 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 "" #: ../Doc/faq/design.rst:478 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, Python works " "with anything that implements malloc() and free() properly." msgstr "" #: ../Doc/faq/design.rst:485 msgid "" "In Jython, the following code (which is fine in CPython) will probably run " "out of file descriptors long before it runs out of memory::" msgstr "" #: ../Doc/faq/design.rst:492 msgid "" "Using the current reference counting and destructor scheme, each new " "assignment to f closes the previous file. Using GC, this is not " "guaranteed. 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 GC::" msgstr "" #: ../Doc/faq/design.rst:504 msgid "Why isn't all memory freed when Python exits?" msgstr "" #: ../Doc/faq/design.rst:506 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:513 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:518 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:520 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 ensemble. Par exemple, " "un repère cartésien est correctement représenté comme un *tuple* de deux ou " "trois nombres." #: ../Doc/faq/design.rst:527 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:534 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:541 msgid "How are lists implemented?" msgstr "Comment est-ce que les listes sont implémentées ?" #: ../Doc/faq/design.rst:543 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:547 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:550 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:557 msgid "How are dictionaries implemented?" msgstr "Comment les dictionnaires sont-ils implémentés ?" #: ../Doc/faq/design.rst:559 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:563 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; for example, \"Python\" hashes to -539294296 " "while \"python\", a string that differs by a single bit, hashes 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 computer science notation -- to retrieve a key. " "It also means that no sorted order of the keys is maintained, and traversing " "the array as the ``.keys()`` and ``.items()`` do will output the " "dictionary's content in some arbitrary jumbled order." msgstr "" #: ../Doc/faq/design.rst:576 msgid "Why must dictionary keys be immutable?" msgstr "Pourquoi les clés du dictionnaire sont immuables ?" #: ../Doc/faq/design.rst:578 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:587 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:591 msgid "Some unacceptable solutions that have been proposed:" msgstr "Certaines solutions insatisfaisantes qui ont été proposées :" #: ../Doc/faq/design.rst:593 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:599 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 lèverait une exception de type *KeyError* car l'ID de ``[1, 2]`` " "utilisé 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 mot clé :keyword:`is`." #: ../Doc/faq/design.rst:603 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:607 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:612 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:618 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:642 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:646 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:651 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:658 msgid "Why doesn't list.sort() return the sorted list?" msgstr "" #: ../Doc/faq/design.rst:660 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:666 msgid "" "In Python 2.4 a new built-in function -- :func:`sorted` -- has been added. " "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:676 msgid "How do you specify and enforce an interface spec in Python?" msgstr "" #: ../Doc/faq/design.rst:678 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:683 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` module defines a set of useful ABCs such as :class:" "`~collections.Iterable`, :class:`~collections.Container`, and :class:" "`~collections.MutableMapping`." msgstr "" #: ../Doc/faq/design.rst:690 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:694 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:702 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:710 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:718 msgid "Why is there no goto?" msgstr "Pourquoi n'y a-t-il pas de ``goto`` en Python ?" #: ../Doc/faq/design.rst:720 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:735 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:740 msgid "Why can't raw strings (r-strings) end with a backslash?" msgstr "" #: ../Doc/faq/design.rst:742 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:746 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:753 msgid "" "If you're trying to build Windows pathnames, note that all Windows system " "calls accept forward slashes too::" msgstr "" #: ../Doc/faq/design.rst:758 msgid "" "If you're trying to build a pathname for a DOS command, try e.g. one of ::" msgstr "" #: ../Doc/faq/design.rst:766 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:768 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:776 msgid "In Python, such a construct would be ambiguous." msgstr "En Python, une telle construction serait ambiguë." #: ../Doc/faq/design.rst:778 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:783 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:789 msgid "For instance, take the following incomplete snippet::" msgstr "" #: ../Doc/faq/design.rst:795 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:801 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:808 msgid "write this::" msgstr "" #: ../Doc/faq/design.rst:815 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:821 msgid "Why are colons required for the if/while/def/class statements?" msgstr "" #: ../Doc/faq/design.rst:823 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:829 msgid "versus ::" msgstr "" #: ../Doc/faq/design.rst:834 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:837 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:843 msgid "Why does Python allow commas at the end of lists and tuples?" msgstr "" #: ../Doc/faq/design.rst:845 msgid "" "Python lets you add a trailing comma at the end of lists, tuples, and " "dictionaries::" msgstr "" #: ../Doc/faq/design.rst:856 msgid "There are several reasons to allow this." msgstr "Il y a plusieurs raisons d'accepter cela." #: ../Doc/faq/design.rst:858 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:863 msgid "" "Accidentally omitting the comma can lead to errors that are hard to " "diagnose. For example::" msgstr "" #: ../Doc/faq/design.rst:873 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:876 msgid "" "Allowing the trailing comma may also make programmatic code generation " "easier." msgstr ""