python-docs-fr/reference/lexical_analysis.po

# SOME DESCRIPTIVE TITLE.
# Copyright (C) 2001-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 3.6\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2018-01-04 15:51+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"
"Language: fr\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:10
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:14
msgid ""
"Python reads program text as Unicode code points; the encoding of a source "
"file can be given by an encoding declaration and defaults to UTF-8, see :pep:"
"`3120` for details.  If the source file cannot be decoded, a :exc:"
"`SyntaxError` is raised."
msgstr ""

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

#: ../Doc/reference/lexical_analysis.rst:27
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:33
msgid "Logical lines"
msgstr "Lignes logiques"

#: ../Doc/reference/lexical_analysis.rst:37
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:47
msgid "Physical lines"
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:49
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:56
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:64
msgid "Comments"
msgstr "Commentaires"

#: ../Doc/reference/lexical_analysis.rst:68
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:77
msgid "Encoding declarations"
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:81
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:90
msgid "which is recognized also by GNU Emacs, and ::"
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:94
msgid "which is recognized by Bram Moolenaar's VIM."
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:96
msgid ""
"If no encoding declaration is found, the default encoding is UTF-8.  In "
"addition, if the first bytes of the file are the UTF-8 byte-order mark "
"(``b'\\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:101
msgid ""
"If an encoding is declared, the encoding name must be recognized by Python. "
"The encoding is used for all lexical analysis, including string literals, "
"comments and identifiers."
msgstr ""

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

#: ../Doc/reference/lexical_analysis.rst:115
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:126
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:136
msgid "Implicit line joining"
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:138
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:146
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:156
msgid "Blank lines"
msgstr "Lignes vierges"

#: ../Doc/reference/lexical_analysis.rst:160
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 interactive interpreter, 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:171
msgid "Indentation"
msgstr "Indentation"

#: ../Doc/reference/lexical_analysis.rst:175
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:179
msgid ""
"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:187
msgid ""
"Indentation is rejected as inconsistent if a source file mixes tabs and "
"spaces in a way that makes the meaning dependent on the worth of a tab in "
"spaces; a :exc:`TabError` is raised in that case."
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:191
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:196
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:203
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:206
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:217
msgid ""
"Here is an example of a correctly (though confusingly) indented piece of "
"Python code::"
msgstr ""

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

#: ../Doc/reference/lexical_analysis.rst:242
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:250
msgid "Whitespace between tokens"
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:252
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:262
msgid "Other tokens"
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:264
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:274
msgid "Identifiers and keywords"
msgstr ""

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

#: ../Doc/reference/lexical_analysis.rst:281
msgid ""
"The syntax of identifiers in Python is based on the Unicode standard annex "
"UAX-31, with elaboration and changes as defined below; see also :pep:`3131` "
"for further details."
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:285
msgid ""
"Within the ASCII range (U+0001..U+007F), the valid characters for "
"identifiers are the same as in Python 2.x: the uppercase and lowercase "
"letters ``A`` through ``Z``, the underscore ``_`` and, except for the first "
"character, the digits ``0`` through ``9``."
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:290
msgid ""
"Python 3.0 introduces additional characters from outside the ASCII range "
"(see :pep:`3131`).  For these characters, the classification uses the "
"version of the Unicode Character Database as included in the :mod:"
"`unicodedata` module."
msgstr ""

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

#: ../Doc/reference/lexical_analysis.rst:303
msgid "The Unicode category codes mentioned above stand for:"
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:305
msgid "*Lu* - uppercase letters"
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:306
msgid "*Ll* - lowercase letters"
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:307
msgid "*Lt* - titlecase letters"
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:308
msgid "*Lm* - modifier letters"
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:309
msgid "*Lo* - other letters"
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:310
msgid "*Nl* - letter numbers"
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:311
msgid "*Mn* - nonspacing marks"
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:312
msgid "*Mc* - spacing combining marks"
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:313
msgid "*Nd* - decimal numbers"
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:314
msgid "*Pc* - connector punctuations"
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:315
msgid ""
"*Other_ID_Start* - explicit list of characters in `PropList.txt <http://www."
"unicode.org/Public/9.0.0/ucd/PropList.txt>`_ to support backwards "
"compatibility"
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:318
msgid "*Other_ID_Continue* - likewise"
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:320
msgid ""
"All identifiers are converted into the normal form NFKC while parsing; "
"comparison of identifiers is based on NFKC."
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:323
msgid ""
"A non-normative HTML file listing all valid identifier characters for "
"Unicode 4.1 can be found at https://www.dcl.hpi.uni-potsdam.de/home/loewis/"
"table-3131.html."
msgstr ""

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

#: ../Doc/reference/lexical_analysis.rst:337
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:354
msgid "Reserved classes of identifiers"
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:356
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:370
msgid "``_*``"
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:361
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:`builtins` module.  When not in "
"interactive mode, ``_`` has no special meaning and is not defined. See "
"section :ref:`import`."
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:368
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:378
msgid "``__*__``"
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:373
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:385
msgid "``__*``"
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:381
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:390
msgid "Literals"
msgstr ""

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

#: ../Doc/reference/lexical_analysis.rst:400
msgid "String and Bytes literals"
msgstr ""

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

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

#: ../Doc/reference/lexical_analysis.rst:437
msgid ""
"In plain English: Both types of 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."
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:444
msgid ""
"Bytes literals are always prefixed with ``'b'`` or ``'B'``; they produce an "
"instance of the :class:`bytes` type instead of the :class:`str` type.  They "
"may only contain ASCII characters; bytes with a numeric value of 128 or "
"greater must be expressed with escapes."
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:449
msgid ""
"Both string and bytes literals may optionally be prefixed with a letter "
"``'r'`` or ``'R'``; such strings are called :dfn:`raw strings` and treat "
"backslashes as literal characters.  As a result, in string literals, "
"``'\\U'`` and ``'\\u'`` escapes in raw strings are not treated specially. "
"Given that Python 2.x's raw unicode literals behave differently than Python "
"3.x's the ``'ur'`` syntax is not supported."
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:456
msgid ""
"The ``'rb'`` prefix of raw bytes literals has been added as a synonym of "
"``'br'``."
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:460
msgid ""
"Support for the unicode legacy literal (``u'value'``) was reintroduced to "
"simplify the maintenance of dual Python 2.x and 3.x codebases. See :pep:"
"`414` for more information."
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:465
msgid ""
"A string literal with ``'f'`` or ``'F'`` in its prefix is a :dfn:`formatted "
"string literal`; see :ref:`f-strings`.  The ``'f'`` may be combined with "
"``'r'``, but not with ``'b'`` or ``'u'``, therefore raw formatted strings "
"are possible, but formatted bytes literals are not."
msgstr ""

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

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

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

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

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

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

#: ../Doc/reference/lexical_analysis.rst:483
msgid "Backslash and newline ignored"
msgstr ""

#: ../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 "``\\r``"
msgstr "``\\r``"

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

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

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

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

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

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

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

#: ../Doc/reference/lexical_analysis.rst:505
msgid "(1,3)"
msgstr ""

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

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

#: ../Doc/reference/lexical_analysis.rst:508
msgid "(2,3)"
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:511
msgid "Escape sequences only recognized in string literals are:"
msgstr ""

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

#: ../Doc/reference/lexical_analysis.rst:516
msgid "Character named *name* in the Unicode database"
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:516
msgid "\\(4)"
msgstr "\\(4)"

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

#: ../Doc/reference/lexical_analysis.rst:519
msgid "Character with 16-bit hex value *xxxx*"
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:519
msgid "\\(5)"
msgstr "\\(5)"

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

#: ../Doc/reference/lexical_analysis.rst:522
msgid "Character with 32-bit hex value *xxxxxxxx*"
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:522
msgid "\\(6)"
msgstr "\\(6)"

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

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

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

#: ../Doc/reference/lexical_analysis.rst:535
msgid ""
"In a bytes literal, hexadecimal and octal escapes denote the byte with the "
"given value. In a string literal, these escapes denote a Unicode character "
"with the given value."
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:540
msgid "Support for name aliases [#]_ has been added."
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:544
msgid "Exactly four hex digits are required."
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:547
msgid ""
"Any Unicode character can be encoded this way.  Exactly eight hex digits are "
"required."
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:553
msgid ""
"Unlike Standard C, all unrecognized escape sequences are left in the string "
"unchanged, i.e., *the backslash is left in the result*.  (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 only recognized in string literals fall into the "
"category of unrecognized escapes for bytes literals."
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:560
msgid ""
"Unrecognized escape sequences produce a DeprecationWarning.  In some future "
"version of Python they will be a SyntaxError."
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:564
msgid ""
"Even in a raw literal, quotes can be escaped with a backslash, but the "
"backslash remains in the result; 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 literal 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 literal, *not* as a line "
"continuation."
msgstr ""

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

#: ../Doc/reference/lexical_analysis.rst:579
msgid ""
"Multiple adjacent string or bytes 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:590
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), and formatted string literals may be concatenated "
"with plain string literals."
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:606
msgid "Formatted string literals"
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:610
msgid ""
"A :dfn:`formatted string literal` or :dfn:`f-string` is a string literal "
"that is prefixed with ``'f'`` or ``'F'``.  These strings may contain "
"replacement fields, which are expressions delimited by curly braces ``{}``. "
"While other string literals always have a constant value, formatted strings "
"are really expressions evaluated at run time."
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:616
msgid ""
"Escape sequences are decoded like in ordinary string literals (except when a "
"literal is also marked as a raw string).  After decoding, the grammar for "
"the contents of the string is:"
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:630
msgid ""
"The parts of the string outside curly braces are treated literally, except "
"that any doubled curly braces ``'{{'`` or ``'}}'`` are replaced with the "
"corresponding single curly brace.  A single opening curly bracket ``'{'`` "
"marks a replacement field, which starts with a Python expression.  After the "
"expression, there may be a conversion field, introduced by an exclamation "
"point ``'!'``.  A format specifier may also be appended, introduced by a "
"colon ``':'``.  A replacement field ends with a closing curly bracket "
"``'}'``."
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:639
msgid ""
"Expressions in formatted string literals are treated like regular Python "
"expressions surrounded by parentheses, with a few exceptions. An empty "
"expression is not allowed, and a :keyword:`lambda` expression must be "
"surrounded by explicit parentheses.  Replacement expressions can contain "
"line breaks (e.g. in triple-quoted strings), but they cannot contain "
"comments.  Each expression is evaluated in the context where the formatted "
"string literal appears, in order from left to right."
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:647
msgid ""
"If a conversion is specified, the result of evaluating the expression is "
"converted before formatting.  Conversion ``'!s'`` calls :func:`str` on the "
"result, ``'!r'`` calls :func:`repr`, and ``'!a'`` calls :func:`ascii`."
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:651
msgid ""
"The result is then formatted using the :func:`format` protocol.  The format "
"specifier is passed to the :meth:`__format__` method of the expression or "
"conversion result.  An empty string is passed when the format specifier is "
"omitted.  The formatted result is then included in the final value of the "
"whole string."
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:657
msgid ""
"Top-level format specifiers may include nested replacement fields. These "
"nested fields may include their own conversion fields and :ref:`format "
"specifiers <formatspec>`, but may not include more deeply-nested replacement "
"fields. The :ref:`format specifier mini-language <formatspec>` is the same "
"as that used by the string .format() method."
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:663
msgid ""
"Formatted string literals may be concatenated, but replacement fields cannot "
"be split across literals."
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:666
msgid "Some examples of formatted string literals::"
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:685
msgid ""
"A consequence of sharing the same syntax as regular string literals is that "
"characters in the replacement fields must not conflict with the quoting used "
"in the outer formatted string literal::"
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:692
msgid ""
"Backslashes are not allowed in format expressions and will raise an error::"
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:697
msgid ""
"To include a value in which a backslash escape is required, create a "
"temporary variable."
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:704
msgid ""
"Formatted string literals cannot be used as docstrings, even if they do not "
"include expressions."
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:715
msgid ""
"See also :pep:`498` for the proposal that added formatted string literals, "
"and :meth:`str.format`, which uses a related format string mechanism."
msgstr ""

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

#: ../Doc/reference/lexical_analysis.rst:728
msgid ""
"There are three types of numeric literals: 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:732
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:740
msgid "Integer literals"
msgstr ""

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

#: ../Doc/reference/lexical_analysis.rst:756
msgid ""
"There is no limit for the length of integer literals apart from what can be "
"stored in available memory."
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:759
msgid ""
"Underscores are ignored for determining the numeric value of the literal.  "
"They can be used to group digits for enhanced readability.  One underscore "
"can occur between digits, and after base specifiers like ``0x``."
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:763
msgid ""
"Note that leading zeros in a non-zero decimal number are not allowed. This "
"is for disambiguation with C-style octal literals, which Python used before "
"version 3.0."
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:767
msgid "Some examples of integer literals::"
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:773
#: ../Doc/reference/lexical_analysis.rst:801
msgid "Underscores are now allowed for grouping purposes in literals."
msgstr ""

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

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

#: ../Doc/reference/lexical_analysis.rst:792
msgid ""
"Note that the integer and exponent parts are always 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.  As in integer literals, underscores are supported for digit "
"grouping."
msgstr ""

#: ../Doc/reference/lexical_analysis.rst:797
msgid "Some examples of floating point literals::"
msgstr ""

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

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

#: ../Doc/reference/lexical_analysis.rst:815
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:827
msgid "Operators"
msgstr "Opérateurs"

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

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

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

#: ../Doc/reference/lexical_analysis.rst:857
msgid ""
"The period can also occur in floating-point and imaginary literals.  A "
"sequence of three periods has a special meaning as an ellipsis literal. 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:862
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:869
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:878
msgid "Footnotes"
msgstr "Notes"

#: ../Doc/reference/lexical_analysis.rst:879
msgid "http://www.unicode.org/Public/9.0.0/ucd/NameAliases.txt"
msgstr ""