# 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/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 ""