forked from AFPy/python-docs-fr
380 lines
13 KiB
Plaintext
380 lines
13 KiB
Plaintext
# 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.
|
|
#
|
|
#, 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 <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"
|
|
msgstr ""
|
|
|
|
#: ../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."
|
|
msgstr ""
|
|
|
|
#: ../Doc/howto/doanddont.rst:0
|
|
msgid "Abstract"
|
|
msgstr "Résumé"
|
|
|
|
#: ../Doc/howto/doanddont.rst:12
|
|
msgid ""
|
|
"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."
|
|
msgstr ""
|
|
|
|
#: ../Doc/howto/doanddont.rst:17
|
|
msgid "Language Constructs You Should Not Use"
|
|
msgstr ""
|
|
|
|
#: ../Doc/howto/doanddont.rst:19
|
|
msgid ""
|
|
"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."
|
|
msgstr ""
|
|
|
|
#: ../Doc/howto/doanddont.rst:25
|
|
msgid "from module import \\*"
|
|
msgstr ""
|
|
|
|
#: ../Doc/howto/doanddont.rst:29
|
|
msgid "Inside Function Definitions"
|
|
msgstr ""
|
|
|
|
#: ../Doc/howto/doanddont.rst:31
|
|
msgid ""
|
|
"``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."
|
|
msgstr ""
|
|
|
|
#: ../Doc/howto/doanddont.rst:41
|
|
msgid "At Module Level"
|
|
msgstr ""
|
|
|
|
#: ../Doc/howto/doanddont.rst:43
|
|
msgid ""
|
|
"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 "
|
|
"classes."
|
|
msgstr ""
|
|
|
|
#: ../Doc/howto/doanddont.rst:49
|
|
msgid ""
|
|
"One of the most awful questions asked on the newsgroup is why this code::"
|
|
msgstr ""
|
|
|
|
#: ../Doc/howto/doanddont.rst:54
|
|
msgid ""
|
|
"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."
|
|
msgstr ""
|
|
|
|
#: ../Doc/howto/doanddont.rst:60
|
|
msgid ""
|
|
"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."
|
|
"name``."
|
|
msgstr ""
|
|
|
|
#: ../Doc/howto/doanddont.rst:66
|
|
msgid "When It Is Just Fine"
|
|
msgstr ""
|
|
|
|
#: ../Doc/howto/doanddont.rst:68
|
|
msgid "There are situations in which ``from module import *`` is just fine:"
|
|
msgstr ""
|
|
|
|
#: ../Doc/howto/doanddont.rst:70
|
|
msgid ""
|
|
"The interactive prompt. For example, ``from math import *`` makes Python an "
|
|
"amazing scientific calculator."
|
|
msgstr ""
|
|
|
|
#: ../Doc/howto/doanddont.rst:73
|
|
msgid "When extending a module in C with a module in Python."
|
|
msgstr ""
|
|
|
|
#: ../Doc/howto/doanddont.rst:75
|
|
msgid "When the module advertises itself as ``from import *`` safe."
|
|
msgstr ""
|
|
|
|
#: ../Doc/howto/doanddont.rst:79
|
|
msgid "Unadorned :keyword:`exec`, :func:`execfile` and friends"
|
|
msgstr ""
|
|
|
|
#: ../Doc/howto/doanddont.rst:81
|
|
msgid ""
|
|
"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."
|
|
msgstr ""
|
|
|
|
#: ../Doc/howto/doanddont.rst:87
|
|
msgid "Bad examples::"
|
|
msgstr ""
|
|
|
|
#: ../Doc/howto/doanddont.rst:97
|
|
msgid "Good examples::"
|
|
msgstr ""
|
|
|
|
#: ../Doc/howto/doanddont.rst:112
|
|
msgid "from module import name1, name2"
|
|
msgstr ""
|
|
|
|
#: ../Doc/howto/doanddont.rst:114
|
|
msgid ""
|
|
"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."
|
|
msgstr ""
|
|
|
|
#: ../Doc/howto/doanddont.rst:122
|
|
msgid "Bad example::"
|
|
msgstr ""
|
|
|
|
#: ../Doc/howto/doanddont.rst:132
|
|
msgid "Good example::"
|
|
msgstr ""
|
|
|
|
#: ../Doc/howto/doanddont.rst:144
|
|
msgid "except:"
|
|
msgstr ""
|
|
|
|
#: ../Doc/howto/doanddont.rst:146
|
|
msgid ""
|
|
"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 "
|
|
"process."
|
|
msgstr ""
|
|
|
|
#: ../Doc/howto/doanddont.rst:151
|
|
msgid "The following code shows a great example of why this is bad::"
|
|
msgstr ""
|
|
|
|
#: ../Doc/howto/doanddont.rst:158
|
|
msgid ""
|
|
"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\"``."
|
|
msgstr ""
|
|
|
|
#: ../Doc/howto/doanddont.rst:163
|
|
msgid "A better way to write the above is ::"
|
|
msgstr ""
|
|
|
|
#: ../Doc/howto/doanddont.rst:170
|
|
msgid ""
|
|
"When this is run, Python will produce a traceback showing the :exc:"
|
|
"`NameError`, and it will be immediately apparent what needs to be fixed."
|
|
msgstr ""
|
|
|
|
#: ../Doc/howto/doanddont.rst:175
|
|
msgid ""
|
|
"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."
|
|
msgstr ""
|
|
|
|
#: ../Doc/howto/doanddont.rst:188
|
|
msgid "Exceptions"
|
|
msgstr "Exceptions"
|
|
|
|
#: ../Doc/howto/doanddont.rst:190
|
|
msgid ""
|
|
"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."
|
|
msgstr ""
|
|
|
|
#: ../Doc/howto/doanddont.rst:194
|
|
msgid "The following is a very popular anti-idiom ::"
|
|
msgstr ""
|
|
|
|
#: ../Doc/howto/doanddont.rst:202
|
|
msgid ""
|
|
"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."
|
|
msgstr ""
|
|
|
|
#: ../Doc/howto/doanddont.rst:211
|
|
msgid "Here is a somewhat better way to do it. ::"
|
|
msgstr ""
|
|
|
|
#: ../Doc/howto/doanddont.rst:220
|
|
msgid ""
|
|
"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."
|
|
msgstr ""
|
|
|
|
#: ../Doc/howto/doanddont.rst:225
|
|
msgid ""
|
|
"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 ::"
|
|
msgstr ""
|
|
|
|
#: ../Doc/howto/doanddont.rst:234
|
|
msgid ""
|
|
"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."
|
|
msgstr ""
|
|
|
|
#: ../Doc/howto/doanddont.rst:238
|
|
msgid "So, an even better version of :func:`get_status()` is probably ::"
|
|
msgstr ""
|
|
|
|
#: ../Doc/howto/doanddont.rst:243
|
|
msgid ""
|
|
"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* "
|
|
"caller."
|
|
msgstr ""
|
|
|
|
#: ../Doc/howto/doanddont.rst:247
|
|
msgid ""
|
|
"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."
|
|
msgstr ""
|
|
|
|
#: ../Doc/howto/doanddont.rst:253
|
|
msgid ""
|
|
"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::"
|
|
msgstr ""
|
|
|
|
#: ../Doc/howto/doanddont.rst:263
|
|
msgid "Using the Batteries"
|
|
msgstr ""
|
|
|
|
#: ../Doc/howto/doanddont.rst:265
|
|
msgid ""
|
|
"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."
|
|
msgstr ""
|
|
|
|
#: ../Doc/howto/doanddont.rst:270
|
|
msgid ""
|
|
"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."
|
|
msgstr ""
|
|
|
|
#: ../Doc/howto/doanddont.rst:274
|
|
msgid "Compare::"
|
|
msgstr ""
|
|
|
|
#: ../Doc/howto/doanddont.rst:281
|
|
msgid ""
|
|
"More useful functions in :mod:`os.path`: :func:`basename`, :func:`dirname` "
|
|
"and :func:`splitext`."
|
|
msgstr ""
|
|
|
|
#: ../Doc/howto/doanddont.rst:284
|
|
msgid ""
|
|
"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::"
|
|
msgstr ""
|
|
|
|
#: ../Doc/howto/doanddont.rst:297
|
|
msgid ""
|
|
"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`."
|
|
msgstr ""
|
|
|
|
#: ../Doc/howto/doanddont.rst:303
|
|
msgid "Using Backslash to Continue Statements"
|
|
msgstr ""
|
|
|
|
#: ../Doc/howto/doanddont.rst:305
|
|
msgid ""
|
|
"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::"
|
|
msgstr ""
|
|
|
|
#: ../Doc/howto/doanddont.rst:312
|
|
msgid ""
|
|
"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 "
|
|
"was::"
|
|
msgstr ""
|
|
|
|
#: ../Doc/howto/doanddont.rst:319
|
|
msgid "then it would just be subtly wrong."
|
|
msgstr ""
|
|
|
|
#: ../Doc/howto/doanddont.rst:321
|
|
msgid ""
|
|
"It is usually much better to use the implicit continuation inside "
|
|
"parenthesis:"
|
|
msgstr ""
|
|
|
|
#: ../Doc/howto/doanddont.rst:323
|
|
msgid "This version is bulletproof::"
|
|
msgstr ""
|