python-docs-fr/reference/lexical_analysis.po

# 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/reference/lexical_analysis.rst:6
msgid "Lexical analysis"
msgstr "Analyse lexicale"

#: ../Doc/reference/lexical_analysis.rst:13
msgid ""
"A Python program is read by a *parser*.  Input to the parser is a stream of "
"*tokens*, generated by the *lexical analyzer*.  This chapter describes how "
"the lexical analyzer breaks a file into tokens."
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:17
msgid "Python uses the 7-bit ASCII character set for program text."
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:19
msgid ""
"An encoding declaration can be used to indicate that  string literals and "
"comments use an encoding different from ASCII."
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:23
msgid ""
"For compatibility with older versions, Python only warns if it finds 8-bit "
"characters; those warnings should be corrected by either declaring an "
"explicit encoding, or using escape sequences if those bytes are binary data, "
"instead of characters."
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:28
msgid ""
"The run-time character set depends on the I/O devices connected to the "
"program but is generally a superset of ASCII."
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:31
msgid ""
"**Future compatibility note:** It may be tempting to assume that the "
"character set for 8-bit characters is ISO Latin-1 (an ASCII superset that "
"covers most western languages that use the Latin alphabet), but it is "
"possible that in the future Unicode text editors will become common.  These "
"generally use the UTF-8 encoding, which is also an ASCII superset, but with "
"very different use for the characters with ordinals 128-255.  While there is "
"no consensus on this subject yet, it is unwise to assume either Latin-1 or "
"UTF-8, even though the current implementation appears to favor Latin-1.  "
"This applies both to the source character set and the run-time character set."
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:45
msgid "Line structure"
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:49
msgid "A Python program is divided into a number of *logical lines*."
msgstr "Un programme en Python est divisé en *lignes logiques*."

#: ../Doc/reference/lexical_analysis.rst:55
msgid "Logical lines"
msgstr "Lignes logiques"

#: ../Doc/reference/lexical_analysis.rst:63
msgid ""
"The end of a logical line is represented by the token NEWLINE.  Statements "
"cannot cross logical line boundaries except where NEWLINE is allowed by the "
"syntax (e.g., between statements in compound statements). A logical line is "
"constructed from one or more *physical lines* by following the explicit or "
"implicit *line joining* rules."
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:73
msgid "Physical lines"
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:75
msgid ""
"A physical line is a sequence of characters terminated by an end-of-line "
"sequence.  In source files, any of the standard platform line termination "
"sequences can be used - the Unix form using ASCII LF (linefeed), the Windows "
"form using the ASCII sequence CR LF (return followed by linefeed), or the "
"old Macintosh form using the ASCII CR (return) character.  All of these "
"forms can be used equally, regardless of platform."
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:82
msgid ""
"When embedding Python, source code strings should be passed to Python APIs "
"using the standard C conventions for newline characters (the ``\\n`` "
"character, representing ASCII LF, is the line terminator)."
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:90
msgid "Comments"
msgstr "Commentaires"

#: ../Doc/reference/lexical_analysis.rst:96
msgid ""
"A comment starts with a hash character (``#``) that is not part of a string "
"literal, and ends at the end of the physical line.  A comment signifies the "
"end of the logical line unless the implicit line joining rules are invoked. "
"Comments are ignored by the syntax; they are not tokens."
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:105
msgid "Encoding declarations"
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:109
msgid ""
"If a comment in the first or second line of the Python script matches the "
"regular expression ``coding[=:]\\s*([-\\w.]+)``, this comment is processed "
"as an encoding declaration; the first group of this expression names the "
"encoding of the source code file. The encoding declaration must appear on a "
"line of its own. If it is the second line, the first line must also be a "
"comment-only line. The recommended forms of an encoding expression are ::"
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:118
msgid "which is recognized also by GNU Emacs, and ::"
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:122
msgid ""
"which is recognized by Bram Moolenaar's VIM. In addition, if the first bytes "
"of the file are the UTF-8 byte-order mark (``'\\xef\\xbb\\xbf'``), the "
"declared file encoding is UTF-8 (this is supported, among others, by "
"Microsoft's :program:`notepad`)."
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:127
msgid ""
"If an encoding is declared, the encoding name must be recognized by Python. "
"The encoding is used for all lexical analysis, in particular to find the end "
"of a string, and to interpret the contents of Unicode literals. String "
"literals are converted to Unicode for syntactical analysis, then converted "
"back to their original encoding before interpretation starts."
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:139
msgid "Explicit line joining"
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:147
msgid ""
"Two or more physical lines may be joined into logical lines using backslash "
"characters (``\\``), as follows: when a physical line ends in a backslash "
"that is not part of a string literal or comment, it is joined with the "
"following forming a single logical line, deleting the backslash and the "
"following end-of-line character.  For example::"
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:158
msgid ""
"A line ending in a backslash cannot carry a comment.  A backslash does not "
"continue a comment.  A backslash does not continue a token except for string "
"literals (i.e., tokens other than string literals cannot be split across "
"physical lines using a backslash).  A backslash is illegal elsewhere on a "
"line outside a string literal."
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:168
msgid "Implicit line joining"
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:170
msgid ""
"Expressions in parentheses, square brackets or curly braces can be split "
"over more than one physical line without using backslashes. For example::"
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:178
msgid ""
"Implicitly continued lines can carry comments.  The indentation of the "
"continuation lines is not important.  Blank continuation lines are allowed. "
"There is no NEWLINE token between implicit continuation lines.  Implicitly "
"continued lines can also occur within triple-quoted strings (see below); in "
"that case they cannot carry comments."
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:188
msgid "Blank lines"
msgstr "Lignes vierges"

#: ../Doc/reference/lexical_analysis.rst:192
msgid ""
"A logical line that contains only spaces, tabs, formfeeds and possibly a "
"comment, is ignored (i.e., no NEWLINE token is generated).  During "
"interactive input of statements, handling of a blank line may differ "
"depending on the implementation of the read-eval-print loop.  In the "
"standard implementation, an entirely blank logical line (i.e. one containing "
"not even whitespace or a comment) terminates a multi-line statement."
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:203
msgid "Indentation"
msgstr "Indentation"

#: ../Doc/reference/lexical_analysis.rst:214
msgid ""
"Leading whitespace (spaces and tabs) at the beginning of a logical line is "
"used to compute the indentation level of the line, which in turn is used to "
"determine the grouping of statements."
msgstr ""
"Des espaces ou tabulations au début d’une ligne logique sont utilisés pour "
"connaître le niveau d’indentation de la ligne, qui est ensuite utilisé pour "
"définir l’ordre des déclarations."

#: ../Doc/reference/lexical_analysis.rst:218
msgid ""
"First, tabs are replaced (from left to right) by one to eight spaces such "
"that the total number of characters up to and including the replacement is a "
"multiple of eight (this is intended to be the same rule as used by Unix).  "
"The total number of spaces preceding the first non-blank character then "
"determines the line's indentation.  Indentation cannot be split over "
"multiple physical lines using backslashes; the whitespace up to the first "
"backslash determines the indentation."
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:226
msgid ""
"**Cross-platform compatibility note:** because of the nature of text editors "
"on non-UNIX platforms, it is unwise to use a mixture of spaces and tabs for "
"the indentation in a single source file.  It should also be noted that "
"different platforms may explicitly limit the maximum indentation level."
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:231
msgid ""
"A formfeed character may be present at the start of the line; it will be "
"ignored for the indentation calculations above.  Formfeed characters "
"occurring elsewhere in the leading whitespace have an undefined effect (for "
"instance, they may reset the space count to zero)."
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:240
msgid ""
"The indentation levels of consecutive lines are used to generate INDENT and "
"DEDENT tokens, using a stack, as follows."
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:243
msgid ""
"Before the first line of the file is read, a single zero is pushed on the "
"stack; this will never be popped off again.  The numbers pushed on the stack "
"will always be strictly increasing from bottom to top.  At the beginning of "
"each logical line, the line's indentation level is compared to the top of "
"the stack. If it is equal, nothing happens. If it is larger, it is pushed on "
"the stack, and one INDENT token is generated.  If it is smaller, it *must* "
"be one of the numbers occurring on the stack; all numbers on the stack that "
"are larger are popped off, and for each number popped off a DEDENT token is "
"generated.  At the end of the file, a DEDENT token is generated for each "
"number remaining on the stack that is larger than zero."
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:254
msgid ""
"Here is an example of a correctly (though confusingly) indented piece of "
"Python code::"
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:269
msgid "The following example shows various indentation errors::"
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:279
msgid ""
"(Actually, the first three errors are detected by the parser; only the last "
"error is found by the lexical analyzer --- the indentation of ``return r`` "
"does not match a level popped off the stack.)"
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:287
msgid "Whitespace between tokens"
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:289
msgid ""
"Except at the beginning of a logical line or in string literals, the "
"whitespace characters space, tab and formfeed can be used interchangeably to "
"separate tokens.  Whitespace is needed between two tokens only if their "
"concatenation could otherwise be interpreted as a different token (e.g., ab "
"is one token, but a b is two tokens)."
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:299
msgid "Other tokens"
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:301
msgid ""
"Besides NEWLINE, INDENT and DEDENT, the following categories of tokens "
"exist: *identifiers*, *keywords*, *literals*, *operators*, and *delimiters*. "
"Whitespace characters (other than line terminators, discussed earlier) are "
"not tokens, but serve to delimit tokens. Where ambiguity exists, a token "
"comprises the longest possible string that forms a legal token, when read "
"from left to right."
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:311
msgid "Identifiers and keywords"
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:317
msgid ""
"Identifiers (also referred to as *names*) are described by the following "
"lexical definitions:"
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:327
msgid "Identifiers are unlimited in length.  Case is significant."
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:333
msgid "Keywords"
msgstr "Mots-clés"

#: ../Doc/reference/lexical_analysis.rst:339
msgid ""
"The following identifiers are used as reserved words, or *keywords* of the "
"language, and cannot be used as ordinary identifiers.  They must be spelled "
"exactly as written here:"
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:353
msgid ""
":const:`None` became a constant and is now recognized by the compiler as a "
"name for the built-in object :const:`None`.  Although it is not a keyword, "
"you cannot assign a different object to it."
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:358
msgid ""
"Using :keyword:`as` and :keyword:`with` as identifiers triggers a warning.  "
"To use them as keywords, enable the ``with_statement`` future feature ."
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:362
msgid ":keyword:`as` and :keyword:`with` are full keywords."
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:369
msgid "Reserved classes of identifiers"
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:371
msgid ""
"Certain classes of identifiers (besides keywords) have special meanings.  "
"These classes are identified by the patterns of leading and trailing "
"underscore characters:"
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:385
msgid "``_*``"
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:376
msgid ""
"Not imported by ``from module import *``.  The special identifier ``_`` is "
"used in the interactive interpreter to store the result of the last "
"evaluation; it is stored in the :mod:`__builtin__` module.  When not in "
"interactive mode, ``_`` has no special meaning and is not defined. See "
"section :ref:`import`."
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:383
msgid ""
"The name ``_`` is often used in conjunction with internationalization; refer "
"to the documentation for the :mod:`gettext` module for more information on "
"this convention."
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:393
msgid "``__*__``"
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:388
msgid ""
"System-defined names. These names are defined by the interpreter and its "
"implementation (including the standard library).  Current system names are "
"discussed in the :ref:`specialnames` section and elsewhere.  More will "
"likely be defined in future versions of Python.  *Any* use of ``__*__`` "
"names, in any context, that does not follow explicitly documented use, is "
"subject to breakage without warning."
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:400
msgid "``__*``"
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:396
msgid ""
"Class-private names.  Names in this category, when used within the context "
"of a class definition, are re-written to use a mangled form to help avoid "
"name clashes between \"private\" attributes of base and derived classes. See "
"section :ref:`atom-identifiers`."
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:405
msgid "Literals"
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:411
msgid "Literals are notations for constant values of some built-in types."
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:417
msgid "String literals"
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:421
msgid "String literals are described by the following lexical definitions:"
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:438
msgid ""
"One syntactic restriction not indicated by these productions is that "
"whitespace is not allowed between the :token:`stringprefix` and the rest of "
"the string literal. The source character set is defined by the encoding "
"declaration; it is ASCII if no encoding declaration is given in the source "
"file; see section :ref:`encodings`."
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:450
msgid ""
"In plain English: String literals can be enclosed in matching single quotes "
"(``'``) or double quotes (``\"``).  They can also be enclosed in matching "
"groups of three single or double quotes (these are generally referred to as "
"*triple-quoted strings*).  The backslash (``\\``) character is used to "
"escape characters that otherwise have a special meaning, such as newline, "
"backslash itself, or the quote character.  String literals may optionally be "
"prefixed with a letter ``'r'`` or ``'R'``; such strings are called :dfn:`raw "
"strings` and use different rules for interpreting backslash escape "
"sequences.  A prefix of ``'u'`` or ``'U'`` makes the string a Unicode "
"string.  Unicode strings use the Unicode character set as defined by the "
"Unicode Consortium and ISO 10646.  Some additional escape sequences, "
"described below, are available in Unicode strings. A prefix of ``'b'`` or "
"``'B'`` is ignored in Python 2; it indicates that the literal should become "
"a bytes literal in Python 3 (e.g. when code is automatically converted with "
"2to3).  A ``'u'`` or ``'b'`` prefix may be followed by an ``'r'`` prefix."
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:466
msgid ""
"In triple-quoted strings, unescaped newlines and quotes are allowed (and are "
"retained), except that three unescaped quotes in a row terminate the "
"string.  (A \"quote\" is the character used to open the string, i.e. either "
"``'`` or ``\"``.)"
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:476
msgid ""
"Unless an ``'r'`` or ``'R'`` prefix is present, escape sequences in strings "
"are interpreted according to rules similar to those used by Standard C.  The "
"recognized escape sequences are:"
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:481
msgid "Escape Sequence"
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:481
msgid "Meaning"
msgstr "Signification"

#: ../Doc/reference/lexical_analysis.rst:481
msgid "Notes"
msgstr "Notes"

#: ../Doc/reference/lexical_analysis.rst:483
msgid "``\\newline``"
msgstr "``\\newline``"

#: ../Doc/reference/lexical_analysis.rst:483
msgid "Ignored"
msgstr "Ignoré"

#: ../Doc/reference/lexical_analysis.rst:485
msgid "``\\\\``"
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:485
msgid "Backslash (``\\``)"
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:487
msgid "``\\'``"
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:487
msgid "Single quote (``'``)"
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:489
msgid "``\\\"``"
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:489
msgid "Double quote (``\"``)"
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:491
msgid "``\\a``"
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:491
msgid "ASCII Bell (BEL)"
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:493
msgid "``\\b``"
msgstr "``\\b``"

#: ../Doc/reference/lexical_analysis.rst:493
msgid "ASCII Backspace (BS)"
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:495
msgid "``\\f``"
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:495
msgid "ASCII Formfeed (FF)"
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:497
msgid "``\\n``"
msgstr "``\\n``"

#: ../Doc/reference/lexical_analysis.rst:497
msgid "ASCII Linefeed (LF)"
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:499
msgid "``\\N{name}``"
msgstr "``\\N{name}``"

#: ../Doc/reference/lexical_analysis.rst:499
msgid "Character named *name* in the Unicode database (Unicode only)"
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:502
msgid "``\\r``"
msgstr "``\\r``"

#: ../Doc/reference/lexical_analysis.rst:502
msgid "ASCII Carriage Return (CR)"
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:504
msgid "``\\t``"
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:504
msgid "ASCII Horizontal Tab (TAB)"
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:506
msgid "``\\uxxxx``"
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:506
msgid "Character with 16-bit hex value *xxxx* (Unicode only)"
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:506
msgid "\\(1)"
msgstr "\\(1)"

#: ../Doc/reference/lexical_analysis.rst:509
msgid "``\\Uxxxxxxxx``"
msgstr "``\\Uxxxxxxxx``"

#: ../Doc/reference/lexical_analysis.rst:509
msgid "Character with 32-bit hex value *xxxxxxxx* (Unicode only)"
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:509
msgid "\\(2)"
msgstr "\\(2)"

#: ../Doc/reference/lexical_analysis.rst:512
msgid "``\\v``"
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:512
msgid "ASCII Vertical Tab (VT)"
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:514
msgid "``\\ooo``"
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:514
msgid "Character with octal value *ooo*"
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:514
msgid "(3,5)"
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:517
msgid "``\\xhh``"
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:517
msgid "Character with hex value *hh*"
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:517
msgid "(4,5)"
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:522
msgid "Notes:"
msgstr "Notes : "

#: ../Doc/reference/lexical_analysis.rst:525
msgid ""
"Individual code units which form parts of a surrogate pair can be encoded "
"using this escape sequence."
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:529
msgid ""
"Any Unicode character can be encoded this way, but characters outside the "
"Basic Multilingual Plane (BMP) will be encoded using a surrogate pair if "
"Python is compiled to use 16-bit code units (the default)."
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:534
msgid "As in Standard C, up to three octal digits are accepted."
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:537
msgid "Unlike in Standard C, exactly two hex digits are required."
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:540
msgid ""
"In a string literal, hexadecimal and octal escapes denote the byte with the "
"given value; it is not necessary that the byte encodes a character in the "
"source character set. In a Unicode literal, these escapes denote a Unicode "
"character with the given value."
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:547
msgid ""
"Unlike Standard C, all unrecognized escape sequences are left in the string "
"unchanged, i.e., *the backslash is left in the string*.  (This behavior is "
"useful when debugging: if an escape sequence is mistyped, the resulting "
"output is more easily recognized as broken.)  It is also important to note "
"that the escape sequences marked as \"(Unicode only)\" in the table above "
"fall into the category of unrecognized escapes for non-Unicode string "
"literals."
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:554
msgid ""
"When an ``'r'`` or ``'R'`` prefix is present, a character following a "
"backslash is included in the string without change, and *all backslashes are "
"left in the string*.  For example, the string literal ``r\"\\n\"`` consists "
"of two characters: a backslash and a lowercase ``'n'``.  String quotes can "
"be escaped with a backslash, but the backslash remains in the string; for "
"example, ``r\"\\\"\"`` is a valid string literal consisting of two "
"characters: a backslash and a double quote; ``r\"\\\"`` is not a valid "
"string literal (even a raw string cannot end in an odd number of "
"backslashes).  Specifically, *a raw string cannot end in a single backslash* "
"(since the backslash would escape the following quote character).  Note also "
"that a single backslash followed by a newline is interpreted as those two "
"characters as part of the string, *not* as a line continuation."
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:567
msgid ""
"When an ``'r'`` or ``'R'`` prefix is used in conjunction with a ``'u'`` or "
"``'U'`` prefix, then the ``\\uXXXX`` and ``\\UXXXXXXXX`` escape sequences "
"are processed while  *all other backslashes are left in the string*. For "
"example, the string literal ``ur\"\\u0062\\n\"`` consists of three Unicode "
"characters: 'LATIN SMALL LETTER B', 'REVERSE SOLIDUS', and 'LATIN SMALL "
"LETTER N'. Backslashes can be escaped with a preceding backslash; however, "
"both remain in the string.  As a result, ``\\uXXXX`` escape sequences are "
"only recognized when there are an odd number of backslashes."
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:580
msgid "String literal concatenation"
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:582
msgid ""
"Multiple adjacent string literals (delimited by whitespace), possibly using "
"different quoting conventions, are allowed, and their meaning is the same as "
"their concatenation.  Thus, ``\"hello\" 'world'`` is equivalent to ``"
"\"helloworld\"``.  This feature can be used to reduce the number of "
"backslashes needed, to split long strings conveniently across long lines, or "
"even to add comments to parts of strings, for example::"
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:593
msgid ""
"Note that this feature is defined at the syntactical level, but implemented "
"at compile time.  The '+' operator must be used to concatenate string "
"expressions at run time.  Also note that literal concatenation can use "
"different quoting styles for each component (even mixing raw strings and "
"triple quoted strings)."
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:602
msgid "Numeric literals"
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:618
msgid ""
"There are four types of numeric literals: plain integers, long integers, "
"floating point numbers, and imaginary numbers.  There are no complex "
"literals (complex numbers can be formed by adding a real number and an "
"imaginary number)."
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:622
msgid ""
"Note that numeric literals do not include a sign; a phrase like ``-1`` is "
"actually an expression composed of the unary operator '``-``' and the "
"literal ``1``."
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:630
msgid "Integer and long integer literals"
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:632
msgid ""
"Integer and long integer literals are described by the following lexical "
"definitions:"
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:647
msgid ""
"Although both lower case ``'l'`` and upper case ``'L'`` are allowed as "
"suffix for long integers, it is strongly recommended to always use ``'L'``, "
"since the letter ``'l'`` looks too much like the digit ``'1'``."
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:651
msgid ""
"Plain integer literals that are above the largest representable plain "
"integer (e.g., 2147483647 when using 32-bit arithmetic) are accepted as if "
"they were long integers instead. [#]_  There is no limit for long integer "
"literals apart from what can be stored in available memory."
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:656
msgid ""
"Some examples of plain integer literals (first row) and long integer "
"literals (second and third rows)::"
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:667
msgid "Floating point literals"
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:669
msgid ""
"Floating point literals are described by the following lexical definitions:"
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:679
msgid ""
"Note that the integer and exponent parts of floating point numbers can look "
"like octal integers, but are interpreted using radix 10.  For example, "
"``077e010`` is legal, and denotes the same number as ``77e10``. The allowed "
"range of floating point literals is implementation-dependent. Some examples "
"of floating point literals::"
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:687
msgid ""
"Note that numeric literals do not include a sign; a phrase like ``-1`` is "
"actually an expression composed of the unary operator ``-`` and the literal "
"``1``."
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:695
msgid "Imaginary literals"
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:697
msgid "Imaginary literals are described by the following lexical definitions:"
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:702
msgid ""
"An imaginary literal yields a complex number with a real part of 0.0.  "
"Complex numbers are represented as a pair of floating point numbers and have "
"the same restrictions on their range.  To create a complex number with a "
"nonzero real part, add a floating point number to it, e.g., ``(3+4j)``.  "
"Some examples of imaginary literals::"
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:714
msgid "Operators"
msgstr "Opérateurs"

#: ../Doc/reference/lexical_analysis.rst:718
msgid "The following tokens are operators:"
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:727
msgid ""
"The comparison operators ``<>`` and ``!=`` are alternate spellings of the "
"same operator.  ``!=`` is the preferred spelling; ``<>`` is obsolescent."
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:734
msgid "Delimiters"
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:738
msgid "The following tokens serve as delimiters in the grammar:"
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:747
msgid ""
"The period can also occur in floating-point and imaginary literals.  A "
"sequence of three periods has a special meaning as an ellipsis in slices. "
"The second half of the list, the augmented assignment operators, serve "
"lexically as delimiters, but also perform an operation."
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:752
msgid ""
"The following printing ASCII characters have special meaning as part of "
"other tokens or are otherwise significant to the lexical analyzer:"
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:761
msgid ""
"The following printing ASCII characters are not used in Python.  Their "
"occurrence outside string literals and comments is an unconditional error:"
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:769
msgid "Footnotes"
msgstr "Notes"

#: ../Doc/reference/lexical_analysis.rst:770
msgid ""
"In versions of Python prior to 2.4, octal and hexadecimal literals in the "
"range just above the largest representable plain integer but below the "
"largest unsigned 32-bit number (on a machine using 32-bit arithmetic), "
"4294967296, were taken as the negative plain integer obtained by subtracting "
"4294967296 from their unsigned value."
msgstr ""