2. 字句解析

A Python program is read by a parser. Input to the parser is a stream of tokens, generated by the lexical analyzer (also known as the tokenizer). This chapter describes how the lexical analyzer breaks a file into tokens.

Python はプログラムテキストを Unicode コードポイントとして読み込みます。ソースファイルのエンコーディングはエンコーディング宣言で与えられ、デフォルトは UTF-8 です。詳細は PEP 3120 を参照してください。ソースファイルがデコードできなければ、 SyntaxError が送出されます。

2.1. 行構造

Python プログラムは多数の 論理行 (logical lines) に分割されます。

2.1.1. 論理行 (logical line)

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.

2.1.2. 物理行 (physical line)

物理行とは、行終端コードで区切られた文字列のことです。 ソースファイルやソース文字列では、各プラットフォームごとの標準の行終端コードを使用することができます。 Unix形式ではASCII LF (行送り: linefeed)文字、 Windows形式ではASCII 配列の CR LF (復帰: return に続いて行送り) 、 Macintosh形式ではASCII CR (復帰) 文字です。 これら全ての形式のコードは、違うプラットフォームでも等しく使用することができます。 入力の末尾も、最後の物理行の暗黙的な終端としての役割を果たします。

Pythonに埋め込む場合には、標準のC言語の改行文字の変換規則 (ASCII LFを表現した文字コード \n が行終端となります) に従って、 Python APIにソースコードを渡す必要があります。

2.1.3. コメント (Comments)

コメントは文字列リテラル内に入っていないハッシュ文字 (#) から始まり、同じ物理行の末端で終わります。 非明示的な行継続規則が適用されていない限り、コメントは論理行を終端させます。 コメントは構文上無視されます。

2.1.4. エンコード宣言 (encoding declaration)

Python スクリプト中の一行目か二行目にあるコメントが正規表現 coding[=:]\s*([-\w.]+) にマッチする場合、コメントはエンコード宣言として処理されます; この表現の最初のグループがソースコードファイルのエンコードを指定します。エンコード宣言は自身の行になければなりません。二行目にある場合、一行目もコメントのみの行でなければなりません。エンコード宣言式として推奨する形式は

# -*- coding: <encoding-name> -*-

これは GNU Emacs で認識できます。または

# vim:fileencoding=<encoding-name>

これは、Bram Moolenar による VIM が認識できる形式です。

If no encoding declaration is found, the default encoding is UTF-8. If the implicit or explicit encoding of a file is UTF-8, an initial UTF-8 byte-order mark (b'\xef\xbb\xbf') is ignored rather than being a syntax error.

エンコーディングが宣言される場合、そのエンコーディング名は Python によって認識できなければなりません (標準エンコーディング を参照してください)。宣言されたエンコーディングは、例えば文字列リテラル、コメント、識別子などの、全ての字句解析に使われます。

2.1.5. 明示的な行継続

二つまたはそれ以上の物理行を論理行としてつなげるためには、バックスラッシュ文字 (\) を使って以下のようにします: 物理行が文字列リテラルやコメント中の文字でないバックスラッシュで終わっている場合、後続する行とつなげて一つの論理行を構成し、バックスラッシュおよびバックスラッシュの後ろにある行末文字を削除します。例えば:

if 1900 < year < 2100 and 1 <= month <= 12 \
   and 1 <= day <= 31 and 0 <= hour < 24 \
   and 0 <= minute < 60 and 0 <= second < 60:   # Looks like a valid date
        return 1

バックスラッシュで終わる行にはコメントを入れることはできません。また、バックスラッシュを使ってコメントを継続することはできません。バックスラッシュが文字列リテラル中にある場合を除き、バックスラッシュの後ろにトークンを継続することはできません (すなわち、物理行内の文字列リテラル以外のトークンをバックスラッシュを使って分断することはできません)。上記以外の場所では、文字列リテラル外にあるバックスラッシュはどこにあっても不正となります。

2.1.6. 非明示的な行継続

丸括弧 (parentheses)、角括弧 (square bracket) 、および波括弧 (curly brace) 内の式は、バックスラッシュを使わずに一行以上の物理行に分割することができます。例えば:

month_names = ['Januari', 'Februari', 'Maart',      # These are the
               'April',   'Mei',      'Juni',       # Dutch names
               'Juli',    'Augustus', 'September',  # for the months
               'Oktober', 'November', 'December']   # of the year

非明示的に継続された行にはコメントを含めることができます。継続行のインデントは重要ではありません。空の継続行を書くことができます。非明示的な継続行中には、NEWLINE トークンは存在しません。非明示的な行の継続は、三重クオートされた文字列 (下記参照) でも発生します; この場合には、コメントを含めることができません。

2.1.7. 空行

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 (that is, one containing not even whitespace or a comment) terminates a multi-line statement.

2.1.8. インデント

論理行の行頭にある、先頭の空白 (スペースおよびタブ) の連なりは、その行のインデントレベルを計算するために使われます。インデントレベルは、実行文のグループ化方法を決定するために用いられます。

タブは (左から右の方向に) 1 つにつき 8 つのスペースで置き換えられ、置き換え後の文字数は 8 の倍数になります (Unix で使われている規則と同じになるよう意図されています)。そして、最初の非空白文字までのスペースの総数が、その行のインデントを決定します。インデントは、バックスラッシュで複数の物理行に分割できません; 最初のバックスラッシュまでの空白がインデントを決定します。

ソースファイルがタブとスペースを混在させ、その意味づけがタブのスペース換算数に依存するようなら、インデントは不合理なものとして却下されます。その場合は TabError が送出されます。

プラットフォーム間の互換性に関する注意: 非 UNIX プラットフォームにおけるテキストエディタの性質上、一つのソースファイル内でタブとインデントを混在させて使うのは賢明ではありません。また、プラットフォームによっては、最大インデントレベルを明示的に制限しているかもしれません。

フォームフィード文字が行の先頭にあっても構いません; フォームフィード文字は上のインデントレベル計算時には無視されます。フォームフィード文字が先頭の空白中の他の場所にある場合、その影響は未定義です (例えば、スペースの数を 0 にリセットするかもしれません)。

The indentation levels of consecutive lines are used to generate INDENT and DEDENT tokens, using a stack, as follows.

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.

以下の例に正しく (しかし当惑させるように) インデントされた Python コードの一部を示します:

def perm(l):
        # Compute the list of all permutations of l
    if len(l) <= 1:
                  return [l]
    r = []
    for i in range(len(l)):
             s = l[:i] + l[i+1:]
             p = perm(s)
             for x in p:
              r.append(l[i:i+1] + x)
    return r

以下の例は、様々なインデントエラーになります:

 def perm(l):                       # error: first line indented
for i in range(len(l)):             # error: not indented
    s = l[:i] + l[i+1:]
        p = perm(l[:i] + l[i+1:])   # error: unexpected indent
        for x in p:
                r.append(l[i:i+1] + x)
            return r                # error: inconsistent dedent

(実際は、最初の 3 つのエラーはパーザによって検出されます; 最後のエラーのみが字句解析器で見つかります --- return r のインデントは、スタックから逐次除去されていくどのインデントレベル値とも一致しません)

2.1.9. トークン間の空白

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. For example, ab is one token, but a b is two tokens. However, +a and + a both produce two tokens, + and a, as +a is not a valid token.

2.1.10. End marker

At the end of non-interactive input, the lexical analyzer generates an ENDMARKER token.

2.2. その他のトークン

Besides NEWLINE, INDENT and DEDENT, the following categories of tokens exist: identifiers and keywords (NAME), literals (such as NUMBER and STRING), and other symbols (operators and delimiters, OP). Whitespace characters (other than logical 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.

2.3. Names (identifiers and keywords)

NAME tokens represent identifiers, keywords, and soft keywords.

Within the ASCII range (U+0001..U+007F), the valid characters for names include the uppercase and lowercase letters (A-Z and a-z), the underscore _ and, except for the first character, the digits 0 through 9.

Names must contain at least one character, but have no upper length limit. Case is significant.

Besides A-Z, a-z, _ and 0-9, names can also use "letter-like" and "number-like" characters from outside the ASCII range, as detailed below.

All identifiers are converted into the normalization form NFKC while parsing; comparison of identifiers is based on NFKC.

Formally, the first character of a normalized identifier must belong to the set id_start, which is the union of:

• Unicode category <Lu> - uppercase letters (includes A to Z)

• Unicode category <Ll> - lowercase letters (includes a to z)

• Unicode category <Lt> - titlecase letters

• Unicode category <Lm> - modifier letters

• Unicode category <Lo> - other letters

• Unicode category <Nl> - letter numbers

• {"_"} - the underscore

• <Other_ID_Start> - an explicit set of characters in PropList.txt to support backwards compatibility

The remaining characters must belong to the set id_continue, which is the union of:

• all characters in id_start

• Unicode category <Nd> - decimal numbers (includes 0 to 9)

• Unicode category <Pc> - connector punctuations

• Unicode category <Mn> - nonspacing marks

• Unicode category <Mc> - spacing combining marks

• <Other_ID_Continue> - another explicit set of characters in PropList.txt to support backwards compatibility

Unicode categories use the version of the Unicode Character Database as included in the unicodedata module.

These sets are based on the Unicode standard annex UAX-31. See also PEP 3131 for further details.

Even more formally, names are described by the following lexical definitions:

NAME:         xid_start xid_continue*
id_start:     <Lu> | <Ll> | <Lt> | <Lm> | <Lo> | <Nl> | "_" | <Other_ID_Start>
id_continue:  id_start | <Nd> | <Pc> | <Mn> | <Mc> | <Other_ID_Continue>
xid_start:    <all characters in id_start whose NFKC normalization is
               in (id_start xid_continue*)">
xid_continue: <all characters in id_continue whose NFKC normalization is
               in (id_continue*)">
identifier:   <NAME, except keywords>

A non-normative listing of all valid identifier characters as defined by Unicode is available in the DerivedCoreProperties.txt file in the Unicode Character Database.

2.3.1. キーワード (keyword)

The following names 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:

False      await      else       import     pass
None       break      except     in         raise
True       class      finally    is         return
and        continue   for        lambda     try
as         def        from       nonlocal   while
assert     del        global     not        with
async      elif       if         or         yield

2.3.2. ソフトキーワード

Added in version 3.10.

Some names are only reserved under specific contexts. These are known as soft keywords:

• match, case, and _, when used in the match statement.

• type, when used in the type statement.

These syntactically act as keywords in their specific contexts, but this distinction is done at the parser level, not when tokenizing.

As soft keywords, their use in the grammar is possible while still preserving compatibility with existing code that uses these names as identifier names.

バージョン 3.12 で変更: type is now a soft keyword.

2.3.3. 予約済みの識別子種 (reserved classes of identifiers)

ある種の (キーワードを除く) 識別子には、特殊な意味があります。これらの識別子種は、先頭や末尾にあるアンダースコア文字のパターンで区別されます:

_*

Not imported by from module import *.

_

In a case pattern within a match statement, _ is a soft keyword that denotes a wildcard.

Separately, the interactive interpreter makes the result of the last evaluation available in the variable _. (It is stored in the builtins module, alongside built-in functions like print.)

Elsewhere, _ is a regular identifier. It is often used to name "special" items, but it is not special to Python itself.

注釈

名前 _ は、しばしば国際化 (internationalization) と共に用いられます; この慣習についての詳しい情報は、 gettext を参照してください。

It is also commonly used for unused variables.

__*__

システムで定義された (system-defined) 名前です。非公式には"dunder"な名前と呼ばれます(訳注: double underscoresの略)。これらの名前はインタープリタと (標準ライブラリを含む) 実装上で定義されています。 現行のシステムでの名前は 特殊メソッド名 などで話題に挙げられています。 Python の将来のバージョンではより多くの名前が定義されることになります。このドキュメントで明記されている用法に従わない、 あらゆる __*__ の名前は、いかなるコンテキストにおける利用でも、警告無く損害を引き起こすことがあります。

__*

クラスプライベート (class-private) な名前です。このカテゴリに属する名前は、クラス定義のコンテキスト上で用いられた場合、基底クラスと派生クラスの "プライベートな" 属性間で名前衝突が起こるのを防ぐために書き直されます。 識別子 (identifier、または名前 (name)) を参照してください。

2.4. リテラル

リテラル (literal) とは、いくつかの組み込み型の定数を表記したものです。

2.4.1. 文字列およびバイト列リテラル

文字列リテラルは以下の字句定義で記述されます:

stringliteral:   [stringprefix](shortstring | longstring)
stringprefix:    "r" | "u" | "R" | "U" | "f" | "F" | "t" | "T"
                 | "fr" | "Fr" | "fR" | "FR" | "rf" | "rF" | "Rf" | "RF"
                 | "tr" | "Tr" | "tR" | "TR" | "rt" | "rT" | "Rt" | "RT"
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>

上記の生成規則で示されていない文法的な制限が一つあります。リテラルの stringprefix や bytesprefix と残りの部分の間に空白を入れてはならないことです。ソースコード文字セット (source character set) はエンコーディング宣言で定義されます。エンコーディング宣言がなければ UTF-8 です。節 エンコード宣言 (encoding declaration) を参照してください。

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 give special meaning to otherwise ordinary characters like n, which means 'newline' when escaped (\n). It can also be used to escape characters that otherwise have a special meaning, such as newline, backslash itself, or the quote character. See escape sequences below for examples.

バイト列リテラルには、常に 'b' や 'B' が接頭します。これらによって、 str 型ではなく bytes 型のインスタンスが作成されます。バイト列リテラルは ASCII 文字のみ含むことができます。 128 以上の数値を持つバイトはエスケープして表されなければなりません。

Both string and bytes literals may optionally be prefixed with a letter 'r' or 'R'; such constructs are called raw string literals and raw bytes literals respectively and treat backslashes as literal characters. As a result, in raw string literals, '\U' and '\u' escapes are not treated specially.

Added in version 3.3: raw バイト列リテラルの 'rb' プレフィックスが 'br' の同義語として追加されました。

Python 2.x と 3.x 両対応のコードベースのメンテナンスを単純化するために、レガシー unicode リテラル (u'value') のサポートが再び導入されました。詳細は PEP 414 を参照してください。

'f' または 'F' の接頭辞が付いた文字列リテラルはフォーマット済み文字列リテラル（ formatted string literal ）です。詳細については フォーマット済み文字列リテラル を参照してください。接頭辞の 'f' は 'r' と組み合わせられますが、 'b' や 'u' と組み合わせることはできません。つまりフォーマット済みの raw 文字列リテラルは可ですが、フォーマット済みのバイト列リテラルは不可です。

三重クオートリテラル中には、三連のエスケープされないクオート文字でリテラルを終端してしまわないかぎり、エスケープされていない改行やクオートを書くことができます (さらに、それらはそのまま文字列中に残ります)。(ここでいう "クオート" とは、文字列の囲みを開始するときに使った文字を示し、' か " のいずれかです。)

2.4.1.1. Escape sequences

'r' または 'R' 接頭文字がつかないかぎり、文字列またはバイト列リテラル中のエスケープシーケンスは標準 C で使われているのと同様の法則にしたがって解釈されます。以下に Python で認識されるエスケープシーケンスを示します:

エスケープシーケンス	意味	注釈
\<newline>	バックスラッシュと改行文字が無視されます	(1)
\\	バックスラッシュ (\)
\'	一重引用符 (')
\"	二重引用符 (")
\a	ASCII 端末ベル (BEL)
\b	ASCII バックスペース (BS)
\f	ASCII フォームフィード (FF)
\n	ASCII 行送り (LF)
\r	ASCII 復帰 (CR)
\t	ASCII 水平タブ (TAB)
\v	ASCII 垂直タブ (VT)
\ooo	8 進数値 ooo を持つ文字	(2,4)
\xhh	16 進数値 hh を持つ文字	(3,4)

文字列でのみ認識されるエスケープシーケンスは以下のとおりです:

エスケープシーケンス	意味	注釈
\N{name}	Unicode データベース中で name という名前の文字	(5)
\uxxxx	16-bit の十六進値 xxxx を持つ文字	(6)
\Uxxxxxxxx	32-bit の十六進値 xxxxxxxx を持つ文字	(7)

注釈:

1. A backslash can be added at the end of a line to ignore the newline:

   >>> 'This string will not include \
   ... backslashes or newline characters.'
   'This string will not include backslashes or newline characters.'
   

   The same result can be achieved using triple-quoted strings, or parentheses and string literal concatenation.

2. 標準 C と同じく、最大で 3 桁の 8 進数まで受理します。

   バージョン 3.11 で変更: Octal escapes with value larger than 0o377 produce a DeprecationWarning.

   バージョン 3.12 で変更: Octal escapes with value larger than 0o377 produce a SyntaxWarning. In a future Python version they will be eventually a SyntaxError.

3. 標準 C とは違い、ちょうど 2 桁の 16 進数しか受理されません。

4. バイト列リテラル中では、十六進および八進エスケープは与えられた値のバイトを表します。文字列リテラル中では、エスケープ文字は与えられた値を持つ Unicode 文字を表します。

5. バージョン 3.3 で変更: name aliases [1] に対するサポートが追加されました。

6. ちょうど 4 桁の 16 進数しか受理されません。

7. あらゆるユニコード文字はこのようにしてエンコードすることができます。正確に8文字の16進数字が必要です。

標準の C とは違い、認識されなかったエスケープシーケンスはすべて、そのまま文字列中に残ります。すなわち、バックスラッシュも結果中に残ります。(この挙動はデバッグの際に便利です: エスケープシーケンスが誤入力されたら、その出力結果が失敗しているのが分かりやすくなります。) 文字列中でのみ認識されるエスケープシーケンスは、バイト列リテラルには、認識されないエスケープシーケンスとして分類されるので注意してください。

バージョン 3.6 で変更: Unrecognized escape sequences produce a DeprecationWarning.

バージョン 3.12 で変更: Unrecognized escape sequences produce a SyntaxWarning. In a future Python version they will be eventually a SyntaxError.

raw リテラルでも、引用符はバックスラッシュでエスケープできますが、バックスラッシュ自体も文字列に残ります; 例えば、r"\"" は有効な文字列リテラルで、バックスラッシュと二重引用符からなる文字列を表します; r"\" は無効な文字列リテラルです (raw リテラルを奇数個連なったバックスラッシュで終わらせることはできません)。具体的には、(バックスラッシュが直後のクオート文字をエスケープしてしまうので) raw文字列を単一のバックスラッシュで終わらせることはできません さらに、バックスラッシュの直後に改行がきても、行継続を意味する のではなく、リテラルの一部であるそれら二つの文字として解釈されます。

2.4.2. 文字列リテラルの結合 (concatenation)

文字列やバイト列リテラルは、互いに異なる引用符を使っていても (空白文字で区切っても) 複数隣接させることができます。これは各々の文字列を結合するのと同じ意味を持ちます。したがって、"hello" 'world' は "helloworld" と同じです。この機能を使うと、バックスラッシュを減らしたり、長い文字列を手軽に分離して複数行にまたがらせたり、あるいは部分文字列ごとにコメントを追加することさえできます。例えば:

re.compile("[A-Za-z_]"       # letter or underscore
           "[A-Za-z0-9_]*"   # letter, digit or underscore
          )

この機能は文法レベルで定義されていますが、スクリプトをコンパイルする際の処理として実現されることに注意してください。実行時に文字列表現を結合したければ、 '+' 演算子を使わなければなりません。また、リテラルの結合においては、結合する各要素に異なる引用符形式を使ったり (raw 文字列と三重引用符を混ぜることさえできます) 、フォーマット済み文字列リテラルと通常の文字列リテラルを結合したりすることもできますので注意してください。

2.4.3. f-strings

Added in version 3.6.

フォーマット済み文字列リテラル（ formatted string literal ）または f-string は、接頭辞 'f' または 'F' の付いた文字列リテラルです。これらの文字列には、波括弧 {} で区切られた式である置換フィールドを含めることができます。他の文字列リテラルの場合は内容が常に一定で変わることが無いのに対して、フォーマット済み文字列リテラルは実行時に式として評価されます。

エスケープシーケンスは通常の文字列リテラルと同様にデコードされます (ただしリテラルが raw 文字列でもある場合は除きます) 。エスケープシーケンスをデコードした後は、文字列の内容は次の文法で解釈されます:

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 | replacement_field)*
literal_char:      <any code point except "{", "}" or NULL>

文字列のうち、波括弧で囲まれた部分以外は文字通り解釈されます。ただし、二重波括弧 '{{' および '}}' は単一の波括弧に置き換えられます。単一の開き波括弧 '{' は置換フィールドの始まりを意味し、その中身は Python の式で始まります。(デバッグ時に便利な機能として) 式のテキストと、評価後の値との両者を表示したい場合には、式の後に等号 '=' を加えてください。その後ろには、感嘆符 '!' によって導入される変換フィールドを続けることができます。さらに、':' に続いて書式指定子を追加できます。置換フィールドは単一の閉じ波括弧 '}' で終わります。

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 both lambda and assignment expressions := must be surrounded by explicit parentheses. Each expression is evaluated in the context where the formatted string literal appears, in order from left to right. Replacement expressions can contain newlines in both single-quoted and triple-quoted f-strings and they can contain comments. Everything that comes after a # inside a replacement field is a comment (even closing braces and quotes). In that case, replacement fields must be closed in a different line.

>>> f"abc{a # This is a comment }"
... + 3}"
'abc5'

バージョン 3.7 で変更: Python 3.7 より前のバージョンでは、await 式および async for 句を含む内包表記は、実装に伴う問題の都合により許されていませんでした。

バージョン 3.12 で変更: Prior to Python 3.12, comments were not allowed inside f-string replacement fields.

等号 '=' が指定されたとき、出力文字列は、式のテキスト表現、等号 '='、および評価された式を含みます。開き波括弧 '{' の直後、式の中、および '=' の後に含まれる空白文字はすべて保存されます。書式指定子が存在しない限り、'=' を指定した場合は、式に対して repr() を適用した結果が出力になります。一方、書式指定子が存在する場合は、変換フィールドで '!r' が指定されていない限り、デフォルトで str() が適用されます。

Added in version 3.8: 等号 '='。

もし変換フィールドが指定されていた場合、式の評価結果はフォーマットの前に変換されます。変換 '!s' は str() を、 '!r' は repr() を、そして '!a' は ascii() を呼び出します。

The result is then formatted using the format() protocol. The format specifier is passed to the __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.

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. The format specifier mini-language is the same as that used by the str.format() method.

フォーマット済み文字列リテラルは他の文字列リテラルと結合できますが、置換フィールドを複数のリテラルに分割して書くことはできません。

フォーマット済み文字列リテラルの例をいくつか挙げます:

>>> name = "Fred"
>>> f"He said his name is {name!r}."
"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'
>>> today = datetime(year=2017, month=1, day=27)
>>> f"{today:%B %d, %Y}"  # using date format specifier
'January 27, 2017'
>>> f"{today=:%B %d, %Y}" # using date format specifier and debugging
'today=January 27, 2017'
>>> number = 1024
>>> f"{number:#0x}"  # using integer format specifier
'0x400'
>>> foo = "bar"
>>> f"{ foo = }" # preserves whitespace
" foo = 'bar'"
>>> line = "The mill's closed"
>>> f"{line = }"
'line = "The mill\'s closed"'
>>> f"{line = :20}"
"line = The mill's closed   "
>>> f"{line = !r:20}"
'line = "The mill\'s closed" '

Reusing the outer f-string quoting type inside a replacement field is permitted:

>>> a = dict(x=2)
>>> f"abc {a["x"]} def"
'abc 2 def'

バージョン 3.12 で変更: Prior to Python 3.12, reuse of the same quoting type of the outer f-string inside a replacement field was not possible.

Backslashes are also allowed in replacement fields and are evaluated the same way as in any other context:

>>> a = ["a", "b", "c"]
>>> print(f"List a contains:\n{"\n".join(a)}")
List a contains:
a
b
c

バージョン 3.12 で変更: Prior to Python 3.12, backslashes were not permitted inside an f-string replacement field.

フォーマット済み文字列リテラルは、たとえ式を含んでいなかったとしても、 docstring としては使えません。

>>> def foo():
...     f"Not a docstring"
...
>>> foo.__doc__ is None
True

フォーマット済み文字列リテラルを Python に追加した提案 PEP 498 も参照してください。また関連する文字列フォーマットの仕組みを使っている str.format() も参照してください。

2.4.4. 数値リテラル

NUMBER tokens represent numeric literals, of which there are three types: integers, floating-point numbers, and imaginary numbers.

NUMBER: integer | floatnumber | imagnumber

The numeric value of a numeric literal is the same as if it were passed as a string to the int, float or complex class constructor, respectively. Note that not all valid inputs for those constructors are also valid literals.

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.4.1. 整数リテラル

Integer literals denote whole numbers. For example:

7
3
2147483647

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

7922816251426433759354395033679228162514264337593543950336

Underscores can be used to group digits for enhanced readability, and are ignored for determining the numeric value of the literal. For example, the following literals are equivalent:

100_000_000_000
100000000000
1_00_00_00_00_000

Underscores can only occur between digits. For example, _123, 321_, and 123__321 are not valid literals.

Integers can be specified in binary (base 2), octal (base 8), or hexadecimal (base 16) using the prefixes 0b, 0o and 0x, respectively. Hexadecimal digits 10 through 15 are represented by letters A-F, case-insensitive. For example:

0b100110111
0b_1110_0101
0o177
0o377
0xdeadbeef
0xDead_Beef

An underscore can follow the base specifier. For example, 0x_1f is a valid literal, but 0_x1f and 0x__1f are not.

Leading zeros in a non-zero decimal number are not allowed. For example, 0123 is not a valid literal. This is for disambiguation with C-style octal literals, which Python used before version 3.0.

Formally, integer literals are described by the following lexical definitions:

integer:      decinteger | bininteger | octinteger | hexinteger | zerointeger
decinteger:   nonzerodigit (["_"] digit)*
bininteger:   "0" ("b" | "B") (["_"] bindigit)+
octinteger:   "0" ("o" | "O") (["_"] octdigit)+
hexinteger:   "0" ("x" | "X") (["_"] hexdigit)+
zerointeger:  "0"+ (["_"] "0")*
nonzerodigit: "1"..."9"
digit:        "0"..."9"
bindigit:     "0" | "1"
octdigit:     "0"..."7"
hexdigit:     digit | "a"..."f" | "A"..."F"

バージョン 3.6 で変更: グループ化を目的としたリテラル中のアンダースコアが許されるようになりました。

2.4.4.2. Floating-point literals

Floating-point (float) literals, such as 3.14 or 1.5, denote approximations of real numbers.

They consist of integer and fraction parts, each composed of decimal digits. The parts are separated by a decimal point, .:

2.71828
4.0

Unlike in integer literals, leading zeros are allowed in the numeric parts. For example, 077.010 is legal, and denotes the same number as 77.10.

As in integer literals, single underscores may occur between digits to help readability:

96_485.332_123
3.14_15_93

Either of these parts, but not both, can be empty. For example:

10.  # (equivalent to 10.0)
.001  # (equivalent to 0.001)

Optionally, the integer and fraction may be followed by an exponent: the letter e or E, followed by an optional sign, + or -, and a number in the same format as the integer and fraction parts. The e or E represents "times ten raised to the power of":

1.0e3  # (represents 1.0×10³, or 1000.0)
1.166e-5  # (represents 1.166×10⁻⁵, or 0.00001166)
6.02214076e+23  # (represents 6.02214076×10²³, or 602214076000000000000000.)

In floats with only integer and exponent parts, the decimal point may be omitted:

1e3  # (equivalent to 1.e3 and 1.0e3)
0e0  # (equivalent to 0.)

Formally, floating-point literals are described by the following lexical definitions:

floatnumber:
   | digitpart "." [digitpart] [exponent]
   | "." digitpart [exponent]
   | digitpart exponent
digitpart: digit (["_"] digit)*
exponent:  ("e" | "E") ["+" | "-"] digitpart

バージョン 3.6 で変更: グループ化を目的としたリテラル中のアンダースコアが許されるようになりました。

2.4.4.3. 虚数 (imaginary) リテラル

Python has complex number objects, but no complex literals. Instead, imaginary literals denote complex numbers with a zero real part.

For example, in math, the complex number 3+4.2i is written as the real number 3 added to the imaginary number 4.2i. Python uses a similar syntax, except the imaginary unit is written as j rather than i:

3+4.2j

This is an expression composed of the integer literal 3, the operator '+', and the imaginary literal 4.2j. Since these are three separate tokens, whitespace is allowed between them:

3 + 4.2j

No whitespace is allowed within each token. In particular, the j suffix, may not be separated from the number before it.

The number before the j has the same syntax as a floating-point literal. Thus, the following are valid imaginary literals:

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

Unlike in a floating-point literal the decimal point can be omitted if the imaginary number only has an integer part. The number is still evaluated as a floating-point number, not an integer:

10j
0j
1000000000000000000000000j   # equivalent to 1e+24j

The j suffix is case-insensitive. That means you can use J instead:

3.14J   # equivalent to 3.14j

Formally, imaginary literals are described by the following lexical definition:

imagnumber: (floatnumber | digitpart) ("j" | "J")

2.5. 演算子

以下のトークンは演算子です:

+       -       *       **      /       //      %      @
<<      >>      &       |       ^       ~       :=
<       >       <=      >=      ==      !=

2.6. デリミタ (delimiter)

以下のトークンは文法上のデリミタとして働きます:

(       )       [       ]       {       }
,       :       !       .       ;       @       =
->      +=      -=      *=      /=      //=     %=
@=      &=      |=      ^=      >>=     <<=     **=

ピリオドは浮動小数点数や虚数リテラル中にも置けます。ピリオド三つの列はスライス表記における省略符号 (ellipsis) リテラルとして特別な意味を持ちます。リスト後半の累算代入演算子 (augmented assignment operator) は、字句的にはデリミタとして振舞いますが、演算も行います。

以下の印字可能 ASCII 文字は、他のトークンの一部として特殊な意味を持っていたり、字句解析器にとって重要な意味を持っています:

'       "       #       \

以下の印字可能 ASCII 文字は、Python では使われていません。これらの文字が文字列リテラルやコメントの外にある場合、無条件にエラーとなります:

$       ?       `

脚注

[1]

https://www.unicode.org/Public/16.0.0/ucd/NameAliases.txt