python-docs-fr/howto/doanddont.po at 2.7 · python/python-docs-fr

379 lines (319 loc) · 12.7 KB
# SOME DESCRIPTIVE TITLE.
# Copyright (C) 1990-2016, Python Software Foundation
# This file is distributed under the same license as the Python package.
# FIRST AUTHOR <EMAIL@ADDRESS>, YEAR.
"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 <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
#: ../Doc/howto/doanddont.rst:3
msgid "Idioms and Anti-Idioms in Python"
#: ../Doc/howto/doanddont.rst:5
msgid "Moshe Zadka"
msgstr "Moshe Zadka"
#: ../Doc/howto/doanddont.rst:7
msgid "This document is placed in the public domain."
#: ../Doc/howto/doanddont.rst:0
msgid "Abstract"
msgstr "Résumé"
#: ../Doc/howto/doanddont.rst:12
"This document can be considered a companion to the tutorial. It shows how to "
"use Python, and even more importantly, how *not* to use Python."
#: ../Doc/howto/doanddont.rst:17
msgid "Language Constructs You Should Not Use"
#: ../Doc/howto/doanddont.rst:19
"While Python has relatively few gotchas compared to other languages, it "
"still has some constructs which are only useful in corner cases, or are "
"plain dangerous."
#: ../Doc/howto/doanddont.rst:25
msgid "from module import \\*"
#: ../Doc/howto/doanddont.rst:29
msgid "Inside Function Definitions"
#: ../Doc/howto/doanddont.rst:31
"``from module import *`` is *invalid* inside function definitions. While "
"many versions of Python do not check for the invalidity, it does not make it "
"more valid, no more than having a smart lawyer makes a man innocent. Do not "
"use it like that ever. Even in versions where it was accepted, it made the "
"function execution slower, because the compiler could not be certain which "
"names were local and which were global. In Python 2.1 this construct causes "
"warnings, and sometimes even errors."
#: ../Doc/howto/doanddont.rst:41
msgid "At Module Level"
#: ../Doc/howto/doanddont.rst:43
"While it is valid to use ``from module import *`` at module level it is "
"usually a bad idea. For one, this loses an important property Python "
"otherwise has --- you can know where each toplevel name is defined by a "
"simple \"search\" function in your favourite editor. You also open yourself "
"to trouble in the future, if some module grows additional functions or "
#: ../Doc/howto/doanddont.rst:49
"One of the most awful questions asked on the newsgroup is why this code::"
#: ../Doc/howto/doanddont.rst:54
"does not work. Of course, it works just fine (assuming you have a file "
"called \"www\".) But it does not work if somewhere in the module, the "
"statement ``from os import *`` is present. The :mod:`os` module has a "
"function called :func:`open` which returns an integer. While it is very "
"useful, shadowing a builtin is one of its least useful properties."
#: ../Doc/howto/doanddont.rst:60
"Remember, you can never know for sure what names a module exports, so either "
"take what you need --- ``from module import name1, name2``, or keep them in "
"the module and access on a per-need basis ---  ``import module;print module."
#: ../Doc/howto/doanddont.rst:66
msgid "When It Is Just Fine"
#: ../Doc/howto/doanddont.rst:68
msgid "There are situations in which ``from module import *`` is just fine:"
#: ../Doc/howto/doanddont.rst:70
"The interactive prompt. For example, ``from math import *`` makes Python an "
"amazing scientific calculator."
#: ../Doc/howto/doanddont.rst:73
msgid "When extending a module in C with a module in Python."
#: ../Doc/howto/doanddont.rst:75
msgid "When the module advertises itself as ``from import *`` safe."
#: ../Doc/howto/doanddont.rst:79
msgid "Unadorned :keyword:`exec`, :func:`execfile` and friends"
#: ../Doc/howto/doanddont.rst:81
"The word \"unadorned\" refers to the use without an explicit dictionary, in "
"which case those constructs evaluate code in the *current* environment. This "
"is dangerous for the same reasons ``from import *`` is dangerous --- it "
"might step over variables you are counting on and mess up things for the "
"rest of your code. Simply do not do that."
#: ../Doc/howto/doanddont.rst:87
msgid "Bad examples::"
#: ../Doc/howto/doanddont.rst:97
msgid "Good examples::"
#: ../Doc/howto/doanddont.rst:112
msgid "from module import name1, name2"
#: ../Doc/howto/doanddont.rst:114
"This is a \"don't\" which is much weaker than the previous \"don't\"s but is "
"still something you should not do if you don't have good reasons to do that. "
"The reason it is usually a bad idea is because you suddenly have an object "
"which lives in two separate namespaces. When the binding in one namespace "
"changes, the binding in the other will not, so there will be a discrepancy "
"between them. This happens when, for example, one module is reloaded, or "
"changes the definition of a function at runtime."
#: ../Doc/howto/doanddont.rst:122
msgid "Bad example::"
#: ../Doc/howto/doanddont.rst:132
msgid "Good example::"
#: ../Doc/howto/doanddont.rst:144
msgid "except:"
#: ../Doc/howto/doanddont.rst:146
"Python has the ``except:`` clause, which catches all exceptions. Since "
"*every* error in Python raises an exception, using ``except:`` can make many "
"programming errors look like runtime problems, which hinders the debugging "
#: ../Doc/howto/doanddont.rst:151
msgid "The following code shows a great example of why this is bad::"
#: ../Doc/howto/doanddont.rst:158
"The second line triggers a :exc:`NameError`, which is caught by the except "
"clause. The program will exit, and the error message the program prints will "
"make you think the problem is the readability of ``\"file\"`` when in fact "
"the real error has nothing to do with ``\"file\"``."
#: ../Doc/howto/doanddont.rst:163
msgid "A better way to write the above is ::"
#: ../Doc/howto/doanddont.rst:170
"When this is run, Python will produce a traceback showing the :exc:"
"`NameError`, and it will be immediately apparent what needs to be fixed."
#: ../Doc/howto/doanddont.rst:175
"Because ``except:`` catches *all* exceptions, including :exc:`SystemExit`, :"
"exc:`KeyboardInterrupt`, and :exc:`GeneratorExit` (which is not an error and "
"should not normally be caught by user code), using a bare ``except:`` is "
"almost never a good idea.  In situations where you need to catch all \"normal"
"\" errors, such as in a framework that runs callbacks, you can catch the "
"base class for all normal exceptions, :exc:`Exception`.  Unfortunately in "
"Python 2.x it is possible for third-party code to raise exceptions that do "
"not inherit from :exc:`Exception`, so in Python 2.x there are some cases "
"where you may have to use a bare ``except:`` and manually re-raise the "
"exceptions you don't want to catch."
#: ../Doc/howto/doanddont.rst:188
msgid "Exceptions"
msgstr "Exceptions"
#: ../Doc/howto/doanddont.rst:190
"Exceptions are a useful feature of Python. You should learn to raise them "
"whenever something unexpected occurs, and catch them only where you can do "
"something about them."
#: ../Doc/howto/doanddont.rst:194
msgid "The following is a very popular anti-idiom ::"
#: ../Doc/howto/doanddont.rst:202
"Consider the case where the file gets deleted between the time the call to :"
"func:`os.path.exists` is made and the time :func:`open` is called. In that "
"case the last line will raise an :exc:`IOError`.  The same thing would "
"happen if *file* exists but has no read permission.  Since testing this on a "
"normal machine on existent and non-existent files makes it seem bugless, the "
"test results will seem fine, and the code will get shipped.  Later an "
"unhandled :exc:`IOError` (or perhaps some other :exc:`EnvironmentError`) "
"escapes to the user, who gets to watch the ugly traceback."
#: ../Doc/howto/doanddont.rst:211
msgid "Here is a somewhat better way to do it. ::"
#: ../Doc/howto/doanddont.rst:220
"In this version, *either* the file gets opened and the line is read (so it "
"works even on flaky NFS or SMB connections), or an error message is printed "
"that provides all the available information on why the open failed, and the "
"application is aborted."
#: ../Doc/howto/doanddont.rst:225
"However, even this version of :func:`get_status` makes too many assumptions "
"--- that it will only be used in a short running script, and not, say, in a "
"long running server. Sure, the caller could do something like ::"
#: ../Doc/howto/doanddont.rst:234
"But there is a better way.  You should try to use as few ``except`` clauses "
"in your code as you can --- the ones you do use will usually be inside calls "
"which should always succeed, or a catch-all in a main function."
#: ../Doc/howto/doanddont.rst:238
msgid "So, an even better version of :func:`get_status()` is probably ::"
#: ../Doc/howto/doanddont.rst:243
"The caller can deal with the exception if it wants (for example, if it tries "
"several files in a loop), or just let the exception filter upwards to *its* "
#: ../Doc/howto/doanddont.rst:247
"But the last version still has a serious problem --- due to implementation "
"details in CPython, the file would not be closed when an exception is raised "
"until the exception handler finishes; and, worse, in other implementations "
"(e.g., Jython) it might not be closed at all regardless of whether or not an "
"exception is raised."
#: ../Doc/howto/doanddont.rst:253
"The best version of this function uses the ``open()`` call as a context "
"manager, which will ensure that the file gets closed as soon as the function "
"returns::"
#: ../Doc/howto/doanddont.rst:263
msgid "Using the Batteries"
#: ../Doc/howto/doanddont.rst:265
"Every so often, people seem to be writing stuff in the Python library again, "
"usually poorly. While the occasional module has a poor interface, it is "
"usually much better to use the rich standard library and data types that "
"come with Python than inventing your own."
#: ../Doc/howto/doanddont.rst:270
"A useful module very few people know about is :mod:`os.path`. It  always has "
"the correct path arithmetic for your operating system, and will usually be "
"much better than whatever you come up with yourself."
#: ../Doc/howto/doanddont.rst:274
msgid "Compare::"
#: ../Doc/howto/doanddont.rst:281
"More useful functions in :mod:`os.path`: :func:`basename`,  :func:`dirname` "
"and :func:`splitext`."
#: ../Doc/howto/doanddont.rst:284
"There are also many useful built-in functions people seem not to be aware of "
"for some reason: :func:`min` and :func:`max` can find the minimum/maximum of "
"any sequence with comparable semantics, for example, yet many people write "
"their own :func:`max`/:func:`min`. Another highly useful function is :func:"
"`reduce` which can be used to repeatly apply a binary operation to a "
"sequence, reducing it to a single value.  For example, compute a factorial "
"with a series of multiply operations::"
#: ../Doc/howto/doanddont.rst:297
"When it comes to parsing numbers, note that :func:`float`, :func:`int` and :"
"func:`long` all accept string arguments and will reject ill-formed strings "
"by raising an :exc:`ValueError`."
#: ../Doc/howto/doanddont.rst:303
msgid "Using Backslash to Continue Statements"
#: ../Doc/howto/doanddont.rst:305
"Since Python treats a newline as a statement terminator, and since "
"statements are often more than is comfortable to put in one line, many "
"people do::"
#: ../Doc/howto/doanddont.rst:312
"You should realize that this is dangerous: a stray space after the ``\\`` "
"would make this line wrong, and stray spaces are notoriously hard to see in "
"editors. In this case, at least it would be a syntax error, but if the code "
#: ../Doc/howto/doanddont.rst:319
msgid "then it would just be subtly wrong."
#: ../Doc/howto/doanddont.rst:321
"It is usually much better to use the implicit continuation inside "
"parenthesis:"
#: ../Doc/howto/doanddont.rst:323
msgid "This version is bulletproof::"
Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

FilesExpand file tree

doanddont.po

Latest commit

History

doanddont.po

File metadata and controls
