forked from AFPy/python-docs-fr
1050 lines
35 KiB
Plaintext
1050 lines
35 KiB
Plaintext
# 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: 2016-10-30 10:40+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 ""
|
|
|
|
#: ../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 ""
|
|
|
|
#: ../Doc/reference/lexical_analysis.rst:33
|
|
msgid "Logical lines"
|
|
msgstr ""
|
|
|
|
#: ../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 ""
|
|
|
|
#: ../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 ""
|
|
|
|
#: ../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 ""
|
|
|
|
#: ../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 ""
|
|
|
|
#: ../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/8.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 ""
|
|
|
|
#: ../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 ""
|
|
"As of Python 3.3 it is possible again to prefix string literals with a ``u`` "
|
|
"prefix to simplify maintenance of dual 2.x and 3.x codebases."
|
|
msgstr ""
|
|
|
|
#: ../Doc/reference/lexical_analysis.rst:452
|
|
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:459
|
|
msgid ""
|
|
"The ``'rb'`` prefix of raw bytes literals has been added as a synonym of "
|
|
"``'br'``."
|
|
msgstr ""
|
|
|
|
#: ../Doc/reference/lexical_analysis.rst:463
|
|
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:468
|
|
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:473
|
|
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:479
|
|
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:484
|
|
#: ../Doc/reference/lexical_analysis.rst:517
|
|
msgid "Escape Sequence"
|
|
msgstr ""
|
|
|
|
#: ../Doc/reference/lexical_analysis.rst:484
|
|
#: ../Doc/reference/lexical_analysis.rst:517
|
|
msgid "Meaning"
|
|
msgstr "Signification"
|
|
|
|
#: ../Doc/reference/lexical_analysis.rst:484
|
|
#: ../Doc/reference/lexical_analysis.rst:517
|
|
msgid "Notes"
|
|
msgstr "Notes"
|
|
|
|
#: ../Doc/reference/lexical_analysis.rst:486
|
|
msgid "``\\newline``"
|
|
msgstr "``\\newline``"
|
|
|
|
#: ../Doc/reference/lexical_analysis.rst:486
|
|
msgid "Backslash and newline ignored"
|
|
msgstr ""
|
|
|
|
#: ../Doc/reference/lexical_analysis.rst:488
|
|
msgid "``\\\\``"
|
|
msgstr ""
|
|
|
|
#: ../Doc/reference/lexical_analysis.rst:488
|
|
msgid "Backslash (``\\``)"
|
|
msgstr ""
|
|
|
|
#: ../Doc/reference/lexical_analysis.rst:490
|
|
msgid "``\\'``"
|
|
msgstr ""
|
|
|
|
#: ../Doc/reference/lexical_analysis.rst:490
|
|
msgid "Single quote (``'``)"
|
|
msgstr ""
|
|
|
|
#: ../Doc/reference/lexical_analysis.rst:492
|
|
msgid "``\\\"``"
|
|
msgstr ""
|
|
|
|
#: ../Doc/reference/lexical_analysis.rst:492
|
|
msgid "Double quote (``\"``)"
|
|
msgstr ""
|
|
|
|
#: ../Doc/reference/lexical_analysis.rst:494
|
|
msgid "``\\a``"
|
|
msgstr ""
|
|
|
|
#: ../Doc/reference/lexical_analysis.rst:494
|
|
msgid "ASCII Bell (BEL)"
|
|
msgstr ""
|
|
|
|
#: ../Doc/reference/lexical_analysis.rst:496
|
|
msgid "``\\b``"
|
|
msgstr "``\\b``"
|
|
|
|
#: ../Doc/reference/lexical_analysis.rst:496
|
|
msgid "ASCII Backspace (BS)"
|
|
msgstr ""
|
|
|
|
#: ../Doc/reference/lexical_analysis.rst:498
|
|
msgid "``\\f``"
|
|
msgstr ""
|
|
|
|
#: ../Doc/reference/lexical_analysis.rst:498
|
|
msgid "ASCII Formfeed (FF)"
|
|
msgstr ""
|
|
|
|
#: ../Doc/reference/lexical_analysis.rst:500
|
|
msgid "``\\n``"
|
|
msgstr "``\\n``"
|
|
|
|
#: ../Doc/reference/lexical_analysis.rst:500
|
|
msgid "ASCII Linefeed (LF)"
|
|
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 "``\\v``"
|
|
msgstr ""
|
|
|
|
#: ../Doc/reference/lexical_analysis.rst:506
|
|
msgid "ASCII Vertical Tab (VT)"
|
|
msgstr ""
|
|
|
|
#: ../Doc/reference/lexical_analysis.rst:508
|
|
msgid "``\\ooo``"
|
|
msgstr ""
|
|
|
|
#: ../Doc/reference/lexical_analysis.rst:508
|
|
msgid "Character with octal value *ooo*"
|
|
msgstr ""
|
|
|
|
#: ../Doc/reference/lexical_analysis.rst:508
|
|
msgid "(1,3)"
|
|
msgstr ""
|
|
|
|
#: ../Doc/reference/lexical_analysis.rst:511
|
|
msgid "``\\xhh``"
|
|
msgstr ""
|
|
|
|
#: ../Doc/reference/lexical_analysis.rst:511
|
|
msgid "Character with hex value *hh*"
|
|
msgstr ""
|
|
|
|
#: ../Doc/reference/lexical_analysis.rst:511
|
|
msgid "(2,3)"
|
|
msgstr ""
|
|
|
|
#: ../Doc/reference/lexical_analysis.rst:514
|
|
msgid "Escape sequences only recognized in string literals are:"
|
|
msgstr ""
|
|
|
|
#: ../Doc/reference/lexical_analysis.rst:519
|
|
msgid "``\\N{name}``"
|
|
msgstr "``\\N{name}``"
|
|
|
|
#: ../Doc/reference/lexical_analysis.rst:519
|
|
msgid "Character named *name* in the Unicode database"
|
|
msgstr ""
|
|
|
|
#: ../Doc/reference/lexical_analysis.rst:519
|
|
msgid "\\(4)"
|
|
msgstr "\\(4)"
|
|
|
|
#: ../Doc/reference/lexical_analysis.rst:522
|
|
msgid "``\\uxxxx``"
|
|
msgstr ""
|
|
|
|
#: ../Doc/reference/lexical_analysis.rst:522
|
|
msgid "Character with 16-bit hex value *xxxx*"
|
|
msgstr ""
|
|
|
|
#: ../Doc/reference/lexical_analysis.rst:522
|
|
msgid "\\(5)"
|
|
msgstr "\\(5)"
|
|
|
|
#: ../Doc/reference/lexical_analysis.rst:525
|
|
msgid "``\\Uxxxxxxxx``"
|
|
msgstr "``\\Uxxxxxxxx``"
|
|
|
|
#: ../Doc/reference/lexical_analysis.rst:525
|
|
msgid "Character with 32-bit hex value *xxxxxxxx*"
|
|
msgstr ""
|
|
|
|
#: ../Doc/reference/lexical_analysis.rst:525
|
|
msgid "\\(6)"
|
|
msgstr "\\(6)"
|
|
|
|
#: ../Doc/reference/lexical_analysis.rst:529
|
|
msgid "Notes:"
|
|
msgstr "Notes : "
|
|
|
|
#: ../Doc/reference/lexical_analysis.rst:532
|
|
msgid "As in Standard C, up to three octal digits are accepted."
|
|
msgstr ""
|
|
|
|
#: ../Doc/reference/lexical_analysis.rst:535
|
|
msgid "Unlike in Standard C, exactly two hex digits are required."
|
|
msgstr ""
|
|
|
|
#: ../Doc/reference/lexical_analysis.rst:538
|
|
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:543
|
|
msgid "Support for name aliases [#]_ has been added."
|
|
msgstr ""
|
|
|
|
#: ../Doc/reference/lexical_analysis.rst:547
|
|
msgid "Exactly four hex digits are required."
|
|
msgstr ""
|
|
|
|
#: ../Doc/reference/lexical_analysis.rst:550
|
|
msgid ""
|
|
"Any Unicode character can be encoded this way. Exactly eight hex digits are "
|
|
"required."
|
|
msgstr ""
|
|
|
|
#: ../Doc/reference/lexical_analysis.rst:556
|
|
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:563
|
|
msgid ""
|
|
"Unrecognized escape sequences produce a DeprecationWarning. In some future "
|
|
"version of Python they will be a SyntaxError."
|
|
msgstr ""
|
|
|
|
#: ../Doc/reference/lexical_analysis.rst:567
|
|
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:580
|
|
msgid "String literal concatenation"
|
|
msgstr ""
|
|
|
|
#: ../Doc/reference/lexical_analysis.rst:582
|
|
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: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), and formatted string literals may be concatenated "
|
|
"with plain string literals."
|
|
msgstr ""
|
|
|
|
#: ../Doc/reference/lexical_analysis.rst:609
|
|
msgid "Formatted string literals"
|
|
msgstr ""
|
|
|
|
#: ../Doc/reference/lexical_analysis.rst:613
|
|
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:619
|
|
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:633
|
|
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:642
|
|
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:650
|
|
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:654
|
|
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:660
|
|
msgid ""
|
|
"Top-level format specifiers may include nested replacement fields. These "
|
|
"nested fields may include their own conversion fields and format specifiers, "
|
|
"but may not include more deeply-nested replacement fields."
|
|
msgstr ""
|
|
|
|
#: ../Doc/reference/lexical_analysis.rst:664
|
|
msgid ""
|
|
"Formatted string literals may be concatenated, but replacement fields cannot "
|
|
"be split across literals."
|
|
msgstr ""
|
|
|
|
#: ../Doc/reference/lexical_analysis.rst:667
|
|
msgid "Some examples of formatted string literals::"
|
|
msgstr ""
|
|
|
|
#: ../Doc/reference/lexical_analysis.rst:680
|
|
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. Also, escape sequences normally "
|
|
"apply to the outer formatted string literal, rather than inner string "
|
|
"literals::"
|
|
msgstr ""
|
|
|
|
#: ../Doc/reference/lexical_analysis.rst:694
|
|
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:701
|
|
msgid "Numeric literals"
|
|
msgstr ""
|
|
|
|
#: ../Doc/reference/lexical_analysis.rst:707
|
|
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:711
|
|
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:719
|
|
msgid "Integer literals"
|
|
msgstr ""
|
|
|
|
#: ../Doc/reference/lexical_analysis.rst:721
|
|
msgid "Integer literals are described by the following lexical definitions:"
|
|
msgstr ""
|
|
|
|
#: ../Doc/reference/lexical_analysis.rst:735
|
|
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:738
|
|
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:742
|
|
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:746
|
|
msgid "Some examples of integer literals::"
|
|
msgstr ""
|
|
|
|
#: ../Doc/reference/lexical_analysis.rst:752
|
|
#: ../Doc/reference/lexical_analysis.rst:784
|
|
msgid "Underscores are now allowed for grouping purposes in literals."
|
|
msgstr ""
|
|
|
|
#: ../Doc/reference/lexical_analysis.rst:759
|
|
msgid "Floating point literals"
|
|
msgstr ""
|
|
|
|
#: ../Doc/reference/lexical_analysis.rst:761
|
|
msgid ""
|
|
"Floating point literals are described by the following lexical definitions:"
|
|
msgstr ""
|
|
|
|
#: ../Doc/reference/lexical_analysis.rst:771
|
|
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:776
|
|
msgid "Some examples of floating point literals::"
|
|
msgstr ""
|
|
|
|
#: ../Doc/reference/lexical_analysis.rst:780
|
|
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:791
|
|
msgid "Imaginary literals"
|
|
msgstr ""
|
|
|
|
#: ../Doc/reference/lexical_analysis.rst:793
|
|
msgid "Imaginary literals are described by the following lexical definitions:"
|
|
msgstr ""
|
|
|
|
#: ../Doc/reference/lexical_analysis.rst:798
|
|
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:810
|
|
msgid "Operators"
|
|
msgstr ""
|
|
|
|
#: ../Doc/reference/lexical_analysis.rst:814
|
|
msgid "The following tokens are operators:"
|
|
msgstr ""
|
|
|
|
#: ../Doc/reference/lexical_analysis.rst:827
|
|
msgid "Delimiters"
|
|
msgstr ""
|
|
|
|
#: ../Doc/reference/lexical_analysis.rst:831
|
|
msgid "The following tokens serve as delimiters in the grammar:"
|
|
msgstr ""
|
|
|
|
#: ../Doc/reference/lexical_analysis.rst:840
|
|
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:845
|
|
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:852
|
|
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:861
|
|
msgid "Footnotes"
|
|
msgstr "Notes"
|
|
|
|
#: ../Doc/reference/lexical_analysis.rst:862
|
|
msgid "http://www.unicode.org/Public/8.0.0/ucd/NameAliases.txt"
|
|
msgstr ""
|