1. はじめに
***********

このリファレンスマニュアルは、Python プログラミング言語自体に関する記
述です。チュートリアルとして書かれたものではありません。

私は本マニュアルをできるだけ正確に書こうとする一方で、文法や字句解析以
外の全てについて、形式化された仕様記述ではなく英語を使うことにしました
。そうすることで、このドキュメントが平均的な読者にとってより読みやすく
なっているはずですが、ややあいまいな部分も残っていることでしょう。従っ
て、もし読者のあなたが火星から来ている人で、このドキュメントだけから
Python を再度実装しようとしているのなら、色々と推測しなければならない
ことがあり、実際にはおそらく全く別の言語を実装する羽目になるでしょう。
逆に、あなたが Python を利用しており、Python 言語のある特定の領域にお
いて、厳密な規則が何か疑問に思った場合、その答えはこのドキュメントで確
実に見つけられることでしょう。もしより形式化された言語定義をお望みなら
、あなたの時間を提供していただいてかまいません --- もしくは、クローン
生成装置でも発明してください :-)。

実装に関する詳細を言語リファレンスのドキュメントに載せすぎるのは危険な
ことです --- 実装は変更されるかもしれず、同じ言語でも異なる実装は異な
った動作をするかもしれないからです。一方、CPython が広く使われている一
つの Python 実装 (別の実装も支持され続けていますが) なので、特定のクセ
については、特に実装によって何らかの制限が加えられている場合には、触れ
ておく価値があります。従って、このテキスト全体にわたって短い "実装に関
する注釈 (imprementation notes)" がちりばめられています。

Python 実装はいずれも、数々の組み込みモジュールと標準モジュールが付属
します。それらについては、 Python 標準ライブラリ でドキュメント化され
ています。いくつかの組み込みモジュールについては、言語定義と重要なかか
わりをもっているときについて触れています。


1.1. 別のPythonの実装
=====================

Pythonの実装としては、群を抜いて有名な実装がひとつ存在しています。それ
以外の実装に関しても、特定のユーザ間で興味が持たれています。

よく知られている実装には以下のものがあります:

CPython
   これは最も保守されている初代のPython実装で、C言語で書かれています。
   ほとんどの場合、言語の新機能がいち早く実装されます。

Jython
   Javaで実装されたPythonです。この実装はJavaアプリケーションのための
   スクリプト言語として、もしくはJavaクラスライブラリを使ったアプリケ
   ーションを作成するために使用することができます。また、Javaライブラ
   リのテストを作成するためにもしばしば使用されています。さらなる情報
   については the Jython website を参照してください。

Python for .NET
   この実装は内部ではCPythonを使用していますが、 .NETアプリケーション
   によって管理されているので、 .NETライブラリを参照することが可能です
   。この実装はBrian Lloydによって作成されました。さらなる情報について
   は、 Python for .NET home page を参照してください。

IronPython
   .NETでPythonを使用するためのもう一つの実装です。Python.NETとは異な
   り、完全にILを生成することができるPythonの実装あり、直接Pythonコー
   ドを.NETアセンブリにコンパイルします。これはJythonの初代の開発者で
   あるJim Huguninによって作られました。さらなる情報については the
   IronPython website を参照してください。

PyPy
   完全にPythonで書かれたPythonの実装です。他の実装には見られない、ス
   タックレスのサポートや、実行時 (Just in Time) コンパイラなどの高度
   な機能をサポートしています。このプロジェクトの一つの目的は、（
   Pythonで書かれていることによって、）インタプリタを簡単に修正できる
   ようにして、言語自体での実験を後押しすることです。さらなる情報は
   the PyPy project's home page にあります。

これらの各実装はこのマニュアルで文書化された言語とは多少異なっている、
もしくは、標準のPythonドキュメントと何処が異なっているかを定めた情報が
公開されているでしょう。あなたが使用している実装上で、代替手段を使う必
要があるかどうかを判断するためには、各実装の仕様書を参照してください。


1.2. 本マニュアルにおける表記法
===============================

The descriptions of lexical analysis and syntax use a grammar notation
that is a mixture of EBNF and PEG. For example:

   name:   letter (letter | digit | "_")*
   letter: "a"..."z" | "A"..."Z"
   digit:  "0"..."9"

In this example, the first line says that a "name" is a "letter"
followed by a sequence of zero or more "letter"s, "digit"s, and
underscores. A "letter" in turn is any of the single characters "'a'"
through "'z'" and "A" through "Z"; a "digit" is a single character
from "0" to "9".

Each rule begins with a name (which identifies the rule that's being
defined) followed by a colon, ":". The definition to the right of the
colon uses the following syntax elements:

* "name": A name refers to another rule. Where possible, it is a link
  to the rule's definition.

  * "TOKEN": An uppercase name refers to a *token*. For the purposes
    of grammar definitions, tokens are the same as rules.

* ""text"", "'text'": Text in single or double quotes must match
  literally (without the quotes). The type of quote is chosen
  according to the meaning of "text":

  * "'if'": A name in single quotes denotes a keyword.

  * ""case"": A name in double quotes denotes a soft-keyword.

  * "'@'": A non-letter symbol in single quotes denotes an "OP" token,
    that is, a delimiter or operator.

* "e1 e2": Items separated only by whitespace denote a sequence. Here,
  "e1" must be followed by "e2".

* "e1 | e2": A vertical bar is used to separate alternatives. It
  denotes PEG's "ordered choice": if "e1" matches, "e2" is not
  considered. In traditional PEG grammars, this is written as a slash,
  "/", rather than a vertical bar. See **PEP 617** for more background
  and details.

* "e*": A star means zero or more repetitions of the preceding item.

* "e+": Likewise, a plus means one or more repetitions.

* "[e]": A phrase enclosed in square brackets means zero or one
  occurrences. In other words, the enclosed phrase is optional.

* "e?": A question mark has exactly the same meaning as square
  brackets: the preceding item is optional.

* "(e)": Parentheses are used for grouping.

The following notation is only used in lexical definitions.

* ""a"..."z"": Two literal characters separated by three dots mean a
  choice of any single character in the given (inclusive) range of
  ASCII characters.

* "<...>": A phrase between angular brackets gives an informal
  description of the matched symbol (for example, "<any ASCII
  character except "\">"), or an abbreviation that is defined in
  nearby text (for example, "<Lu>").

Some definitions also use *lookaheads*, which indicate that an element
must (or must not) match at a given position, but without consuming
any input:

* "&e": a positive lookahead (that is, "e" is required to match)

* "!e": a negative lookahead (that is, "e" is required *not* to match)

The unary operators ("*", "+", "?") bind as tightly as possible; the
vertical bar ("|") binds most loosely.

White space is only meaningful to separate tokens.

Rules are normally contained on a single line, but rules that are too
long may be wrapped:

   literal: stringliteral | bytesliteral
            | integer | floatnumber | imagnumber

Alternatively, rules may be formatted with the first line ending at
the colon, and each alternative beginning with a vertical bar on a new
line. For example:

   literal:
      | stringliteral
      | bytesliteral
      | integer
      | floatnumber
      | imagnumber

This does *not* mean that there is an empty first alternative.


1.2.1. Lexical and Syntactic definitions
----------------------------------------

There is some difference between *lexical* and *syntactic* analysis:
the *lexical analyzer* operates on the individual characters of the
input source, while the *parser* (syntactic analyzer) operates on the
stream of *tokens* generated by the lexical analysis. However, in some
cases the exact boundary between the two phases is a CPython
implementation detail.

The practical difference between the two is that in *lexical*
definitions, all whitespace is significant. The lexical analyzer
discards all whitespace that is not converted to tokens like
"token.INDENT" or "NEWLINE". *Syntactic* definitions then use these
tokens, rather than source characters.

This documentation uses the same BNF grammar for both styles of
definitions. All uses of BNF in the next chapter (字句解析) are
lexical definitions; uses in subsequent chapters are syntactic
definitions.
