Python 3.6.1官方手册：详解语言特性与执行模型

需积分: 10 64 浏览量更新于2024-07-20 收藏 653KB PDF 举报

身份认证购VIP最低享 7 折!

30元优惠券

本资源是Python 3.6.1 的官方参考手册，由Guido van Rossum 和 Python 开发团队编撰，发布于2017年4月20日。它涵盖了Python语言的核心特性、语法、数据模型、执行模型以及标准库中的import系统等关键部分。 1. **介绍** 部分概述了Python作为一种高级编程语言的替代实现，并强调了其易读性、简洁性和动态类型系统的特点。同时，章节介绍了文档的编写目的和联系方式。 2. **词法分析** 是理解Python源代码的第一步，包括行结构、其他特殊符号（如标识符、关键字）、数字和字符串（literals）等基本元素的定义。此外，还有各种运算符和分隔符的详细介绍。 3. **数据模型** 展示了Python对象、值和类型的基础概念，包括标准类型体系、特殊方法名称（如用于描述对象行为的关键函数名），以及引入的协程（coroutines）功能，这是一种轻量级的并发处理方式。 4. **执行模型** 描述了Python程序的结构，如何进行命名和绑定变量，以及异常处理机制。这部分深入解释了程序执行流程的关键环节。 5. **导入系统** 是Python程序设计的重要组成部分，涉及importlib模块的使用，如何创建和管理包，搜索路径的设定，以及如何替换标准的导入机制。特别关注`__main__`模块在运行时的行为和潜在问题。 6. **表达式** 部分详述了不同类型的算术转换、原子操作（如变量、常量和运算符），以及新引入的await表达式（用于异步编程）和power operator。还涵盖了一元和二元算术及位操作。这份手册对于学习和理解Python 3.6.1 版本的语言特性和标准库提供了深入且详尽的指南，对于开发者而言，无论是初学者还是经验丰富的程序员，都是不可或缺的参考资料。通过阅读和实践，用户可以掌握Python的语法、数据处理和模块化编程技巧，以提高编程效率和代码质量。

资源详情

资源推荐

The Python Language Reference, Release 3.6.1

stringliteral ::= [stringprefix](shortstring | longstring)

stringprefix ::= “r” | “u” | “R” | “U” | “f” | “F”

| “fr” | “Fr” | “fR” | “FR” | “rf” | “rF” | “Rf” | “RF”

shortstring ::= “”’ shortstringitem

“”’ | ‘”’ shortstringitem

‘”’

longstring ::= “’‘”’ longstringitem

“’‘”’ | ‘”“”’ longstringitem

‘”“”’

shortstringitem ::= shortstringchar | stringescapeseq

longstringitem ::= longstringchar | stringescapeseq

shortstringchar ::= <any source character except “\” or newline or the quote>

longstringchar ::= <any source character except “\”>

stringescapeseq ::= “\” <any source character>

bytesliteral ::= bytesprefix(shortbytes | longbytes)

bytesprefix ::= “b” | “B” | “br” | “Br” | “bR” | “BR” | “rb” | “rB” | “Rb” | “RB”

shortbytes ::= “”’ shortbytesitem

“”’ | ‘”’ shortbytesitem

‘”’

longbytes ::= “’‘”’ longbytesitem

“’‘”’ | ‘”“”’ longbytesitem

‘”“”’

shortbytesitem ::= shortbyteschar | bytesescapeseq

longbytesitem ::= longbyteschar | bytesescapeseq

shortbyteschar ::= <any ASCII character except “\” or newline or the quote>

longbyteschar ::= <any ASCII character except “\”>

bytesescapeseq ::= “\” <any ASCII character>

One syntactic restriction not indicated by these productions is that whitespace is not allowed between the

stringprefix or bytesprefix and the rest of the literal. The source character set is deﬁned by the encod-

ing declaration; it is UTF-8 if no encoding declaration is given in the source ﬁle; see section Encoding declarations.

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.

Bytes literals are always preﬁxed with ’b’ or ’B’; they produce an instance of the bytes type instead of the str

type. They may only contain ASCII characters; bytes with a numeric value of 128 or greater must be expressed with

escapes.

As of Python 3.3 it is possible again to preﬁx string literals with a u preﬁx to simplify maintenance of dual 2.x and 3.x

codebases.

Both string and bytes literals may optionally be preﬁxed with a letter ’r’ or ’R’; such strings are called 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.

New in version 3.3: The ’rb’ preﬁx of raw bytes literals has been added as a synonym of ’br’.

New in version 3.3: 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.

A string literal with ’f’ or ’F’ in its preﬁx is a formatted string literal; see Formatted string literals. 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.

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 ".)

Unless an ’r’ or ’R’ preﬁx 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:

10 Chapter 2. Lexical analysis

The Python Language Reference, Release 3.6.1

Escape Sequence Meaning Notes

\newline Backslash and newline ignored

\\ Backslash (\)

\’ Single quote (’)

\" Double quote (")

\a ASCII Bell (BEL)

\b ASCII Backspace (BS)

\f ASCII Formfeed (FF)

\n ASCII Linefeed (LF)

\r ASCII Carriage Return (CR)

\t ASCII Horizontal Tab (TAB)

\v ASCII Vertical Tab (VT)

\ooo Character with octal value ooo (1,3)

\xhh Character with hex value hh (2,3)

Escape sequences only recognized in string literals are:

Escape Sequence Meaning Notes

\N{name} Character named name in the Unicode database (4)

\uxxxx Character with 16-bit hex value xxxx (5)

\Uxxxxxxxx Character with 32-bit hex value xxxxxxxx (6)

Notes:

1. As in Standard C, up to three octal digits are accepted.

2. Unlike in Standard C, exactly two hex digits are required.

3. 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.

4. Changed in version 3.3: Support for name aliases

has been added.

5. Exactly four hex digits are required.

6. Any Unicode character can be encoded this way. Exactly eight hex digits are required.

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.

Changed in version 3.6: Unrecognized escape sequences produce a DeprecationWarning. In some future

version of Python they will be a SyntaxError.

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). Speciﬁcally, 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.

2.4.2 String literal concatenation

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 conve-

niently across long lines, or even to add comments to parts of strings, for example:

http://www.unicode.org/Public/8.0.0/ucd/NameAliases.txt

2.4. Literals 11

The Python Language Reference, Release 3.6.1

re.compile("[A-Za-z_]" # letter or underscore

"[A-Za-z0-9_]

" # letter, digit or underscore

)

Note that this feature is deﬁned 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.

2.4.3 Formatted string literals

New in version 3.6.

A formatted string literal or f-string is a string literal that is preﬁxed with ’f’ or ’F’. These strings may contain

replacement ﬁelds, 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.

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:

f_string ::= (literal_char | “{{” | “}}” | replacement_field)

replacement_field ::= “{” f_expression [”!” conversion] [”:” format_spec] “}”

f_expression ::= (conditional_expression | “

” or_expr)

(”,” conditional_expression | ”,” “

” or_expr)

[”,”]

| yield_expression

conversion ::= “s” | “r” | “a”

format_spec ::= (literal_char | NULL | replacement_field)

literal_char ::= <any code point except “{”, “}” or NULL>

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

ﬁeld, which starts with a Python expression. After the expression, there may be a conversion ﬁeld, introduced by an

exclamation point ’!’. A format speciﬁer may also be appended, introduced by a colon ’:’. A replacement ﬁeld

ends with a closing curly bracket ’}’.

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 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.

If a conversion is speciﬁed, the result of evaluating the expression is converted before formatting. Conversion ’!s’

calls str() on the result, ’!r’ calls repr(), and ’!a’ calls ascii().

The result is then formatted using the format() protocol. The format speciﬁer is passed to the __format__()

method of the expression or conversion result. An empty string is passed when the format speciﬁer is omitted. The

formatted result is then included in the ﬁnal value of the whole string.

Top-level format speciﬁers may include nested replacement ﬁelds. These nested ﬁelds may include their own conver-

sion ﬁelds and format speciﬁers, but may not include more deeply-nested replacement ﬁelds.

Formatted string literals may be concatenated, but replacement ﬁelds cannot be split across literals.

Some examples of formatted string literals:

>>> name = "Fred"

>>> f"He said his name is {name!r}."

12 Chapter 2. Lexical analysis

The Python Language Reference, Release 3.6.1

"He said his name is 'Fred'."

>>> f"He said his name is {repr(name)}." # repr() is equivalent to !r

"He said his name is 'Fred'."

>>> width = 10

>>> precision = 4

>>> value = decimal.Decimal("12.34567")

>>> f"result: {value:{width}.{precision}}" # nested fields

'result: 12.35'

A consequence of sharing the same syntax as regular string literals is that characters in the replacement ﬁelds must not

conﬂict with the quoting used in the outer formatted string literal:

f"abc {a["x"]} def" # error: outer string literal ended prematurely

f"abc {a['x']} def" # workaround: use different quoting

Backslashes are not allowed in format expressions and will raise an error:

f"newline: {ord('\n')}" # raises SyntaxError

To include a value in which a backslash escape is required, create a temporary variable.

>>> newline = ord('\n')

>>> f"newline: {newline}"

'newline: 10'

Formatted string literals cannot be used as docstrings, even if they do not include expressions.

>>> def foo():

... f"Not a docstring"

...

>>> foo.__doc__ is None

True

See also PEP 498 for the proposal that added formatted string literals, and str.format(), which uses a related

format string mechanism.

2.4.4 Numeric literals

There are three types of numeric literals: integers, ﬂoating point numbers, and imaginary numbers. There are no

complex literals (complex numbers can be formed by adding a real number and an imaginary number).

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.

2.4.5 Integer literals

Integer literals are described by the following lexical deﬁnitions:

integer ::= decinteger | bininteger | octinteger | hexinteger

decinteger ::= nonzerodigit ([”_”] digit)

| “0”+ ([”_”] “0”)

bininteger ::= “0” (“b” | “B”) ([”_”] bindigit)+

octinteger ::= “0” (“o” | “O”) ([”_”] octdigit)+

hexinteger ::= “0” (“x” | “X”) ([”_”] hexdigit)+

nonzerodigit ::= “1”...”9”

digit ::= “0”...”9”

bindigit ::= “0” | “1”

2.4. Literals 13

The Python Language Reference, Release 3.6.1

octdigit ::= “0”...”7”

hexdigit ::= digit | “a”...”f” | “A”...”F”

There is no limit for the length of integer literals apart from what can be stored in available memory.

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 speciﬁers like 0x.

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.

Some examples of integer literals:

7 2147483647 0o177 0b100110111

3 79228162514264337593543950336 0o377 0xdeadbeef

100_000_000_000 0b_1110_0101

Changed in version 3.6: Underscores are now allowed for grouping purposes in literals.

2.4.6 Floating point literals

Floating point literals are described by the following lexical deﬁnitions:

floatnumber ::= pointfloat | exponentfloat

pointfloat ::= [digitpart] fraction | digitpart ”.”

exponentfloat ::= (digitpart | pointfloat) exponent

digitpart ::= digit ([”_”] digit)

fraction ::= ”.” digitpart

exponent ::= (“e” | “E”) [”+” | “-“] digitpart

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 ﬂoating point literals is implementation-dependent. As in

integer literals, underscores are supported for digit grouping.

Some examples of ﬂoating point literals:

3.14 10. .001 1e100 3.14e-10 0e0 3.14_15_93

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.

Changed in version 3.6: Underscores are now allowed for grouping purposes in literals.

2.4.7 Imaginary literals

Imaginary literals are described by the following lexical deﬁnitions:

imagnumber ::= (floatnumber | digitpart) (“j” | “J”)

An imaginary literal yields a complex number with a real part of 0.0. Complex numbers are represented as a pair of

ﬂoating point numbers and have the same restrictions on their range. To create a complex number with a nonzero real

part, add a ﬂoating point number to it, e.g., (3+4j). Some examples of imaginary literals:

3.14j 10.j 10j .001j 1e100j 3.14e-10j 3.14_15_93j

14 Chapter 2. Lexical analysis

剩余160页未读，继续阅读

粉丝: 0
资源: 4

Python 3.6.1官方手册：详解语言特性与执行模型

Python Pocket Reference, 第五版-带书签目录超清文字版.pdf

Python编程初学者指南.pdf

python3.6.5参考手册 chm

python-3.6.1

protobuf-python-3.6.1

python-3.6.1 Tutorial

python-3.6.1-amd64

python-3.6.1-win64

Python-3.6.1.tgz

python-3.6.1-amd64.exe

python-3.6.1-amd64.zip

python-3.6.1-amd64.rar

python-3.6.1-amd-webinstall.exe

python-3.6.1-embed-win32.zip

Python库 | calfem-python-3.6.1.tar.gz

python-3.6.1-amd64 (1).exe

python-ironic-python-agent-doc-3.6.1-1.el7.noarch.rpm

python2-ironic-python-agent-3.6.1-1.el7.noarch.rpm

一文掌握Python基础知识

最新资源