WTF Python!😱 （Python、まじかよ！）前編

以下の文章はこちらのページを翻訳したものです。

https://github.com/satwikkansal/wtfpython

こちらのGitHubプロジェクト「What the f*ck Python! 😱」は、予想外のコードスニペットを通じてPythonを探求し、理解することを目指しています。多くの言語に翻訳されており、ウェブサイトやノートブック、コマンドラインツールを通じてインタラクティブに学ぶこともできます。

他のモード: Interactive Website | Interactive Notebook | CLI

Pythonは高水準な解釈型のプログラミング言語であり、開発者が快適に利用するために多くの機能を搭載しています。しかし、一見しただけでは理解し難いPythonスニペットの結果というのもあります。

こちらのワクワクするプロジェクトでは、直感に反するスニペットやPythonのあまり知られていない特徴の背後にある正確なメカニズムの解説を試みます。そこまで驚くものではないような例も取り上げられているかもしれませんが、Pythonの面白いところを理解しやすくしてくれます。このプロジェクトはプログラミング言語の奥深さを学ぶ良い手段です。読者であるあなたにとっても興味深いものになるでしょう。

経験豊富なPythonプログラマーの方は、一発で正解が分かるか、お試しください。いくつかの事象は以前に経験されているかもしれません。古い記憶を呼び戻すことができるでしょうか？

P.S. この記事を読むのが二度目以降だという方は、最新版ついてはこちらをご覧ください（最新の改訂で追加された例にはアスタリスクが付いています）。

それでは、始めましょう...

目次

• 例の構造
• 使い方
• 実例
  • セクション: 脳トレチャレンジ！
    • まずは大事なことから！
    • やっかいな文字列
    • 連鎖した操作には注意が必要
    • **is**演算子の落とし穴
    • ハッシュブラウニー
    • 本質的にはみんな同じ
    • 秩序の中の無秩序
    • トライし続けよう！
    • 何のためなのか
    • 評価時間の不一致
    • is notはis notではない
    • 一発でXが勝つ三目並べ！
    • シュレーディンガーの変数
    • 鶏が先か卵が先か
    • サブクラスのリレーション
    • メソッドの等価性と同一性
    • すべて真である
    • 驚きのコンマ
    • 文字列とバックスラッシュ
    • notの結び目
    • 半分のトリプルクォート文字列
    • ブール値の意外な挙動
    • クラス属性とインスタンス属性の違い
    • Noneの生成
    • returnからyield
    • Nan再帰性
    • 不変の変異
    • 外部スコープから消える変数
    • 謎のキー型変換
    • これは分かるかな？
    • 整数の文字列変換が限界を超えるとき
  • セクション: 滑りやすい斜面
    • イテレート中の辞書変更問題
    • しつこいdel操作
    • スコープ外の変数
    • イテレート中のリスト項目削除
    • イテレータのロッシー圧縮
    • ループ変数が漏れる！
    • デフォルトの可変引数に注意！
    • 例外処理の落とし穴
    • 同じオペランド、異なる結果！
    • クラススコープを無視する名前解決
    • 「銀行家の丸め」
    • 藁の中の針
    • Splitsies
    • ワイルドインポート
    • すべてsorted？
    • 真夜中は存在しない？
  • セクション: 隠された宝物たち！
    • Python、空を飛びたいんだけど…
    • なぜgotoなのか
    • カッコつけよう！
    • barryおじさん
    • Pythonでも知っていること：愛は複雑
    • 実は存在するんです！
    • Ellipsis
    • インピニティ
    • マングリングしよう
  • セクション: 見た目に惑わされるな
    • 行をスキップ？
    • テレポートテーション
    • 何かがおかしい...
  • セクション: さまざまなトピック
    • +=の方が早い
    • 巨大な文字列の作成
    • dict 検索の遅延
    • インスタンスdict の膨張
    • その他の小さな発見

例の構造

全ての例は以下のような構造で表示されています:

▶ 面白いタイトル

#コード
#面白いことが起きますよ...

出力（Pythonのバージョン）

>>> トリガーとなる文
何らかの予測できない出力

（場合によっては）ここで一言

💡 解説:

何が起きているのか、なぜ起きているのかの簡単な説明。

#コード
#必要あれば、解説のために例を追加

出力（Pythonのバージョン）

>>> トリガー # 何が起きているのかを簡単に理解するための例
#　正しい出力

注意：全ての例はPython 3.5.2の対話型インタープリタでテストされており、出力の前に特に指定がない限り、全てのPythonバージョンで動作するはずです。

使い方

作者の考える、それぞれの例を最大限に活用するための方法です。

• 例の最初のコードを注意深く読んでください。経験豊富なPythonプログラマーであれば、ほとんどの場合、次に何が起こるかを予測できるでしょう。

• 出力スニペットを読み、

  • あなたが期待するものと同じかどうかをご確認ください。
  • そのような状態になっている理由を正確に理解できていますか？
    • 答えが「いいえ」であれば（全く問題ありません）、深呼吸をして、解説を読んでください。
    • 答えが「はい」であれば、自分のことを褒めた上で、次の例に進んでください。

  P.S.：コマンドラインを使用してWTFPythonを読むこともできます。pypi packageを使用して、

  $ pip install wtfpython -U
  $ wtfpython
  

  ---

👀 例

セクション: 脳トレチャレンジ！

▶ まずは大事なことから！

Python 3.8の「セイウチ」演算子（:=）がなぜか人気を博しています。これについて見てみましょう。

# Pythonバージョン3.8以降

>>> a = "wtf_walrus"
>>> a
'wtf_walrus'

>>> a := "wtf_walrus"
File "<stdin>", line 1
    a := "wtf_walrus"
      ^
SyntaxError: invalid syntax

>>> (a := "wtf_walrus") # これは動作します
'wtf_walrus'
>>> a
'wtf_walrus'

# Pythonバージョン3.8以降

>>> a = 6, 9>>> a
(6, 9)

>>> (a := 6, 9)
(6, 9)
>>> a
6

>>> a, b = 6, 9 # 通常のアンパック>>> a, b
(6, 9)
>>> (a, b = 16, 19) # おっと
  File "<stdin>", line 1
    (a, b = 16, 19)
          ^
SyntaxError: invalid syntax

>>> (a, b := 16, 19) # 変な3つ組が出力されます
(6, 16, 19)

>>> a # aはまだ変わっていません
6

>>> b
16

💡 解説

セイウチ演算子についての軽い復習

セイウチ演算子（:=）はPython 3.8で導入されました。式の中で変数に値を割り当てたい場合に役立ちます。

def some_func():
        # ここで高コストの計算が行われるとします
        # time.sleep(1000)
        return 5

# なので、
if some_func():
        print(some_func()) # 計算が2回行われるのは良くないですね

# もしくは
a = some_func()
if a:
    print(a)

# これで簡潔にできます
if a := some_func():
        print(a)

出力 (> 3.8):

5
5
5

これにより、1行のコードが省略され、some_funcを2回呼び出すことが防がれました。

• 括弧をつけない「代入式」（セイウチ演算子の使用）はトップレベルでは制限されているため、最初の例のa := "wtf_walrus"文でSyntaxErrorが発生しました。括弧をつけると期待通りに機能し、aに割り当てられました。
• 通常、=演算子を含む式の括弧付けは許可されていません。したがって、(a, b = 6, 9)での構文エラーが発生します。
• セイウチ演算子の構文は NAME:= expr の形式で、NAMEは有効な識別子であり、exprは有効な式です。したがって、iterableのパッキングとアンパッキングはサポートされていません。つまり、
  • (a := 6, 9) は ((a := 6), 9) に相当し、最終的には (a, 9) になります（ここで a の値は6です）。

>>> (a := 6, 9) == ((a := 6), 9)
True
>>> x = (a := 696, 9)
>>> x
(696, 9)
>>> x[0] is a # どちらもメモリ上の同じ箇所を参照
True

同様に、(a, b := 16, 19)は(a, (b := 16), 19)に相当し、これはただの3つ組です

▶ やっかいな文字列

>>> a = "some_string">>> id(a)
140420665652016
>>> id("some" + "_" + "string") # 両方のidが同じであることに注意してください。
140420665652016

>>> a = "wtf"
>>> b = "wtf"
>>> a is b
True

>>> a = "wtf!"
>>> b = "wtf!"
>>> a is b
False

>>> a, b = "wtf!", "wtf!">>> a is b # 3.7.xを除く全てのバージョンで
True

>>> a = "wtf!"; b = "wtf!">>> a is b # これは、どこで実行するかによってTrueまたはFalseを出力します（Python shell / ipython / スクリプトとして）
False

# 今度はsome_file.pyファイル内で
a = "wtf!"
b = "wtf!"
print(a is b)

# モジュールを呼び出すとTrueが出力されます！

出力 (< Python3.7 )

>>> 'a' * 20 is 'aaaaaaaaaaaaaaaaaaaa'
True
>>> 'a' * 21 is 'aaaaaaaaaaaaaaaaaaaaa'
False

理にかなっていますよね？

💡 解説:

• 最初と2番目のスニペットの動作は、CPythonの最適化（文字列インターニングと呼ばれる）によるものです。いくつかの場合に新しいオブジェクトを作成するのではなく、既存の不変オブジェクトを使用しようとします。

• 「インターニング」された後、多くの変数がメモリ内の同じ文字列オブジェクトを参照することがあります（これによりメモリを節約できます）。

• 上記のスニペットでは、文字列が暗黙的にインターニングされています。文字列が暗黙的にインターニングされるかどうかの判断は実装によります。いくつかのルールがあるので、文字列がインターニングされるかどうかを推測するのにお使いください：

  • 長さ0と長さ1のすべての文字列はインターニングされる
  • 文字列はコンパイル時にインターニングされる（'wtf'はインターニングされるが、''.join(['w', 't', 'f'])はインターニングされない）
  • ASCIIの文字、数字、アンダースコアで構成されていない文字列はインターニングされない。これが'wtf!'がインターニングされなかった理由（!のため）。（このルールのCPython実装はこちらをご覧ください）
    

• aとbが同じ行で"wtf!"に設定されると、Pythonインタープリタは新しいオブジェクトを作成し、その後すぐに2番目の変数を参照する。別々の行で行うと、"wtf!"が既にオブジェクトとして存在していることを「知らない」（上記の事実によれば"wtf!"は暗黙的にインターニングされないため）。これがコンパイル時の最適化。（この最適化はCPythonの3.7.xバージョンには適用されません。詳細な議論についてはこのissueをご覧ください）。

• 対話型環境（IPythonなど）ではコンパイル単位は単一のステートメントであり、モジュールの場合はモジュール全体。a, b = "wtf!", "wtf!"は単一のステートメントであり、a = "wtf!"; b = "wtf!"は単一行の2つのステートメント。これこそがa = "wtf!"; b = "wtf!"で識別子が異なる理由であり、some_file.pyで呼び出された場合に同じである理由にもなる。

• 4番目のスニペットの出力が突然変わるのは、ピープホール最適化として知られる定数折りたたみによるもの。つまり、式'a'*20はコンパイル中に'aaaaaaaaaaaaaaaaaaaa'に置き換えられ、ランタイム中にいくつかのクロックサイクルを節約する。定数折りたたみは、長さが21未満の文字列に対してのみ行われる。（なぜでしょうか？式'a'*10**10の結果として生成される.pycファイルのサイズを想像してみてください。実装ソースはこちら。）

• 注意：Python 3.7では、定数折りたたみはピープホール最適化から新たなAST最適化に移され、ロジックも少し変更されたので、4番目のスニペットはPython 3.7では機能しません。変更についての詳細はこちら。

▶ 連鎖した操作には注意が必要

>>> (False == False) in [False] # わかります
False
>>> False == (False in [False]) # わかります
False
>>> False == False in [False] # お？
True

>>> True is False == False
False
>>> False is False is False
True

>>> 1 > 0 < 1
True
>>> (1 > 0) < 1
False
>>> 1 > (0 < 1)
False

💡 解説:

https://docs.python.org/3/reference/expressions.html#comparisons によると

形式的には、a, b, c, ..., y, zが式であり、op1, op2, ..., opNが比較演算子である場合、a op1 b op2 c ... y opN zは、a op1 bかつb op2 cかつ...y opN zに相当しますが、各式は最大で一度しか評価されません。

上記の例ではこのような動作がばかげていると感じたかもしれませんが、a == b == cや0 <= x <= 100のようなものに対しては本当に素晴らしいです。

• False is False is Falseは(False is False) and (False is False)に相当します。

• True is False == Falseは(True is False) and (False == False)に相当し、文の最初の部分（True is False）がFalseに評価されるため、全体の式がFalseに評価されます。

• 1 > 0 < 1は(1 > 0) and (0 < 1)に相当し、Trueに評価されます。

• 式(1 > 0) < 1はTrue < 1に相当し、

  >>> int(True)
  1
  >>> True + 1 # この例には関係ありませんが、面白いです。
  2
  

• なので、1 < 1はFalseに評価されます。

▶ is 演算子の落とし穴

以下はネット上でも非常に有名な例です。

>>> a = 256
>>> b = 256
>>> a is b
True

>>> a = 257
>>> b = 257
>>> a is b
False

>>> a = []
>>> b = []
>>> a is b
False

>>> a = tuple()
>>> b = tuple()
>>> a is b
True

出力

>>> a, b = 257, 257
>>> a is b
True

出力 (Python 3.7.x限定)

>>> a, b = 257, 257
>>> a is b
False

💡 解説:

is と == の違い

• is 演算子は、両方のオペランドが同じオブジェクトを参照しているかどうかをチェックします（つまり、オペランドのIDが一致するかどうかをチェックします）。

• == 演算子は、両方のオペランドの値を比較して、それらが同じであるかチェックします。

• つまり is は参照の等価性のためのもので、== は値の等価性のためのものです。わかりやすい例を挙げます。

  >>> class A: pass
  >>> A() is A() # それぞれ異なるメモリ位置の空のオブジェクトです。
  False
  
  

256 は既存のオブジェクトですが 257 はそうではありません

Pythonを起動すると、-5 から 256 までの数が割り当てられます。これらの数は頻繁に使用されるので、準備しておくのは理にかなっています。

https://docs.python.org/3/c-api/long.html からの引用

現在の実装では、-5 から 256 までの全ての整数について、整数オブジェクトの配列が保持されています。その範囲で int を作成すると、既存のオブジェクトへの参照を返すだけです。そのため、1 の値を変更することは理論的に可能です。私は、この場合のPythonの動作は未定義だと考えています。:-)

>>> id(256)
10922528
>>> a = 256
>>> b = 256
>>> id(a)
10922528
>>> id(b)
10922528
>>> id(257)
140084850247312
>>> x = 257
>>> y = 257
>>> id(x)
140084850247440
>>> id(y)
140084850247344

インタープリタが y = 257 を実行する際に、すでに 257 の値の整数が作成されていることを認識できるほど賢くありません。そのため、メモリ内に別のオブジェクトを作成してしまいます。

同様の最適化は、空のタプルのような他の不変オブジェクトにも適用されます。リストは変更可能なので、[] is [] は False を返し、() is () は True を返します。これが第2のスニペットの解説です。第3のスニペットに進みましょう。

同じ行で同じ値で初期化された場合、a と b は同じオブジェクトを参照します。

出力

>>> a, b = 257, 257
>>> id(a)
140640774013296
>>> id(b)
140640774013296
>>> a = 257
>>> b = 257
>>> id(a)
140640774013392
>>> id(b)
140640774013488

• a と b が同じ行で 257 に設定されると、Pythonインタープリタは新しいオブジェクトを作成し、その後すぐに2番目の変数を参照します。別々の行で行うと、すでに 257 がオブジェクトとして存在することを「知りません」。

• これはコンパイラの最適化であり、特に対話型環境に適用されます。ライブインタープリタで2行入力すると、個別にコンパイルされるため、個別に最適化されます。この例を .py ファイルで試すと、ファイルが一度にコンパイルされるため、同じ動作は見られません。この最適化は整数に限らず、他の不変データ型にも適用されます。例えば、「文字列はやっかいな時もある」で取り上げた例と同じく、文字列や浮動小数点数でも動作します。

  >>> a, b = 257.0, 257.0
  >>> a is b
  True
  
  

• なぜ Python 3.7 ではこれが機能しないのでしょうか？抽象的な理由としては、そのようなコンパイラの最適化が実装に依存するためです（つまり、バージョン、OSなどによって変更される可能性があるから）。具体的にどのような実装の変更が問題を引き起こしたのかはまだ調査中ですが、最新情報はこちらのissueで確認できます。

▶ ハッシュブラウニー

some_dict = {}
some_dict[5.5] = "JavaScript"
some_dict[5.0] = "Ruby"
some_dict[5] = "Python"

出力:

>>> some_dict[5.5]
"JavaScript"
>>> some_dict[5.0] # "Ruby"の存在が"Python"によって破壊された？
"Python"
>>> some_dict[5]
"Python"

>>> complex_five = 5 + 0j>>> type(complex_five)
complex
>>> some_dict[complex_five]
"Python"

なぜ"Python"だらけなのでしょうか？

💡 解説:

• Pythonの辞書におけるキーの一意性は、同一性ではなく等価性に基づいています。したがって、5、5.0、5 + 0jは異なる型の別々のオブジェクトですが、これらは等しいため、同時に同じdict（またはset）に存在することはできません。いずれか一つを挿入した後に他の等価ではあるけど異なるキーで検索を試みても、KeyErrorで失敗する代わりに、元のマップされた値が成功するようになります。

  >>> 5 == 5.0 == 5 + 0j
  True
  >>> 5 is not 5.0 is not 5 + 0j
  True
  >>> some_dict = {}
  >>> some_dict[5.0] = "Ruby">>> 5.0 in some_dict
  True
  >>> (5 in some_dict) and (5 + 0j in some_dict)
  True
  
  

これはアイテムを設定する場合にも適用されます。したがって、some_dict[5] = "Python" を行うと、Pythonは等価なキー 5.0 -> "Ruby" で既存のアイテムを見つけ、その場で値を上書きし、元のキーはそのままにします。

>>> some_dict
{5.0: 'Ruby'}
>>> some_dict[5] = "Python"
>>> some_dict
{5.0: 'Python'}

• では、キーを 5.0 から 5 に更新するにはどうすればいいのでしょうか？実際にはその場での更新はできませんが、まずキーを削除し（del some_dict[5.0]）、それから設定する（some_dict[5]）ことで、浮動小数点の 5.0 ではなく整数 5 をキーとして取得することができます。ただし、これが必要となるケースは稀でしょう。

• Pythonはどうやって 5.0 を含む辞書で 5 を見つけたのでしょうか？ハッシュ関数を使用して、すべてのアイテムをスキャンすることなく定数時間でこれを行います。Pythonが辞書でキー foo を探すとき、まず hash(foo) を計算します（これは定数時間で実行されます）。等しいオブジェクトは同じハッシュ値を持つことが要求されているため（こちらのドキュメント参照）、5、5.0、5 + 0j は同じハッシュ値を持ちます。

  >>> 5 == 5.0 == 5 + 0j
  True
  >>> hash(5) == hash(5.0) == hash(5 + 0j)
  True
  

注: 逆は必ずしも真ではありません。ハッシュ値が等しいオブジェクトでも、それ自体が等しくない場合があります。（これはハッシュ衝突として知られ、通常ハッシュが提供する定数時間のパフォーマンスを低下させます。）

▶ 本質的にはみんな同じ

class WTF:
  pass

出力:

>>> WTF() == WTF() # 二つの異なるインスタンスは等しくない
False
>>> WTF() is WTF() # IDも異なる
False
>>> hash(WTF()) == hash(WTF()) # ハッシュ値も異なるべき
True
>>> id(WTF()) == id(WTF())
True

💡 解説:

• id が呼び出されたとき、Pythonは WTF クラスのオブジェクトを作成し、id 関数に渡しました。id 関数はその id（メモリ位置）を取得し、オブジェクトを破棄します。オブジェクトは破棄されます。

• これを連続して二回行うと、Pythonは二番目のオブジェクトにも同じメモリ位置を割り当てます。CPythonにおいて id はオブジェクトのIDとしてメモリ位置を使用するので、二つのオブジェクトのIDは同じになります。

• したがって、オブジェクトのIDはオブジェクトの生存期間に対してのみ一意です。オブジェクトが破棄された後、または作成される前であれば、他の何かが同じIDを持つことがあります。

• では、なぜ is 演算子は False と評価されたのでしょうか？こちらのスニペットで確認しましょう。

  class WTF(object):
    def __init__(self): print("I")
    def __del__(self): print("D")
  

出力:

>>> WTF() is WTF()
I
I
D
D
False
>>> id(WTF()) == id(WTF())
I
D
I
D
True

• ご覧の通り、オブジェクトが破棄される順番が、ここでの違いを生んでいます。

▶ 秩序の中の無秩序

from collections import OrderedDict

dictionary = dict()
dictionary[1] = 'a'; dictionary[2] = 'b';

ordered_dict = OrderedDict()
ordered_dict[1] = 'a'; ordered_dict[2] = 'b';

another_ordered_dict = OrderedDict()
another_ordered_dict[2] = 'b'; another_ordered_dict[1] = 'a';

class DictWithHash(dict):
    """
    A dict that also implements __hash__ magic.
    """
    __hash__ = lambda self: 0

class OrderedDictWithHash(OrderedDict):
    """
    An OrderedDict that also implements __hash__ magic.
    """
    __hash__ = lambda self: 0

出力

>>> dictionary == ordered_dict # a == b であり、
True
>>> dictionary == another_ordered_dict # b == c であれば、
True
>>> ordered_dict == another_ordered_dict # なぜ c == a ではないのか？？
False

# setはユニークな要素のみから構成されることを知っていますが、
# これらの辞書を使ってを作ってみるとどうなるでしょう...

>>> len({dictionary, ordered_dict, another_ordered_dict})
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unhashable type: 'dict'

# 辞書には __hash__ が実装されていないので理にかなっていますが、
# ラッパークラスを使いましょう。
>>> dictionary = DictWithHash()
>>> dictionary[1] = 'a'; dictionary[2] = 'b';
>>> ordered_dict = OrderedDictWithHash()
>>> ordered_dict[1] = 'a'; ordered_dict[2] = 'b';
>>> another_ordered_dict = OrderedDictWithHash()
>>> another_ordered_dict[2] = 'b'; another_ordered_dict[1] = 'a';
>>> len({dictionary, ordered_dict, another_ordered_dict})
1
>>> len({ordered_dict, another_ordered_dict, dictionary}) # 順番を変えています
2

ここでは何が起きているのでしょうか？

💡 解説:

• dictionary、ordered_dict、another_ordered_dict の間で推移的等価性が保持されなかった理由は、OrderedDict クラスで __eq__ メソッドがどのように実装されているかにあります。ドキュメントからの引用です。

  OrderedDictオブジェクト間の等価性テストは順序に敏感であり、list(od1.items())==list(od2.items()) として実装されています。OrderedDictオブジェクトと他のマッピングオブジェクト間の等価性テストは、通常の辞書のように順序に敏感ではありません。

• この動作の等価性の理由は、OrderedDict オブジェクトが通常の辞書が使用される場所で直接代用できるようにするためです。

• では、なぜ順序を変えると生成された set オブジェクトの長さに影響が出たのでしょうか？答えは推移的等価性の欠如に他なりません。setはユニークな要素の「順序なし」コレクションなので、要素が挿入される順序は関係ないはずです。しかし、この場合は関係あります。もう少し詳しく分解してみましょう。

>>> some_set = set()
>>> some_set.add(dictionary) # これは上記スニペットからのマッピングオブジェクトです
>>> ordered_dict in some_set
True
>>> some_set.add(ordered_dict)
>>> len(some_set)
1
>>> another_ordered_dict in some_set
True
>>> some_set.add(another_ordered_dict)
>>> len(some_set)
1

>>> another_set = set()
>>> another_set.add(ordered_dict)
>>> another_ordered_dict in another_set
False
>>> another_set.add(another_ordered_dict)
>>> len(another_set)
2
>>> dictionary in another_set
True
>>> another_set.add(another_ordered_dict)
>>> len(another_set)
2

• つまり、不一致は another_ordered_dict in another_set が False となることによるものなのです。なぜなら、another_set には既に ordered_dict が存在しており、先ほど見たように ordered_dict == another_ordered_dict は False なのです。

▶ トライし続けよう！

def some_func():
    try:
        return 'from_try'
    finally:
        return 'from_finally'

def another_func():
    for _ in range(3):
        try:
            continue
        finally:
            print("Finally!")

def one_more_func(): # よし！
    try:
        for i in range(3):
            try:
                1 / i
            except ZeroDivisionError:
                # ここで例外を投げて、forループの外で処理しましょう
                raise ZeroDivisionError("A trivial divide by zero error")
            finally:
                print("Iteration", i)
                break
    except ZeroDivisionError as e:
        print("Zero division error occurred", e)

出力:

>>> some_func()
'from_finally'

>>> another_func()
Finally!
Finally!
Finally!

>>> 1 / 0
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
ZeroDivisionError: division by zero

>>> one_more_func()
Iteration 0

💡 解説:

• tryブロック内でreturn, break, continue文が実行された場合、finally節も出るときに実行されます。
• 関数の戻り値は、最後に実行されたreturn文によって決定されます。finally節は常に実行されるので、finally節内で実行されるreturn文が常に最後に実行されるものになります。
• ここでの注意点は、finally節がreturnまたはbreak文を実行すると、一時的に保存されていた例外が破棄されることです。

▶ 何のためなのか

some_string = "wtf"
some_dict = {}
for i, some_dict[i] in enumerate(some_string):
    i = 10

出力:

>>> some_dict # インデックス付きのdictが現れる。
{0: 'w', 1: 't', 2: 'f'}

💡 解説:

• Python文法におけるfor文は次のように定義されています：

  for_stmt: 'for' exprlist 'in' testlist ':' suite ['else' ':' suite]
  
  

ここでexprlistは代入のターゲットです。つまり、{exprlist} = {next_value}が反復可能な各アイテムに対して実行されることを意味します。分かりやすくするために、興味深い例を見てみましょう：

for i in range(4):
    print(i)
    i = 10

出力:

0
1
2
3

ループは一度しか実行されないと思いましたか？

💡 解説:

• i = 10の代入文がループの反復に影響を与えないのは、Pythonのforループの動作方法によるものです。各反復の開始前に、イテレータによって提供された次のアイテム（この場合はrange(4)）がアンパックされ、ターゲットリスト変数に割り当てられます（この場合はi）。

• enumerate(some_string)関数は、各反復で新しい値i（増加するカウンタ）とsome_stringからの文字を生成します。それから、辞書some_dictのiキーをその文字に設定します。ループの展開を単純化すると以下のようになります：

  >>> i, some_dict[i] = (0, 'w')
  >>> i, some_dict[i] = (1, 't')
  >>> i, some_dict[i] = (2, 'f')
  >>> some_dict
  
  

▶ 評価時間の不一致

array = [1, 8, 15]
# 典型的なジェネレータ式
gen = (x for x in array if array.count(x) > 0)
array = [2, 8, 22]

出力:

>>> print(list(gen)) # 他の値はどこへ？
[8]

array_1 = [1,2,3,4]
gen_1 = (x for x in array_1)
array_1 = [1,2,3,4,5]

array_2 = [1,2,3,4]
gen_2 = (x for x in array_2)
array_2[:] = [1,2,3,4,5]

出力:

>>> print(list(gen_1))
[1, 2, 3, 4]

>>> print(list(gen_2))
[1, 2, 3, 4, 5]

array_3 = [1, 2, 3]
array_4 = [10, 20, 30]
gen = (i + j for i in array_3 for j in array_4)

array_3 = [4, 5, 6]
array_4 = [400, 500, 600]

出力:

>>> print(list(gen))
[401, 501, 601, 402, 502, 602, 403, 503, 603]

💡 解説:

• ジェネレータ式において、in句は宣言時に評価されますが、条件句は実行時に評価されます。

• したがって、実行時になる前にarrayはリスト[2, 8, 22]に再度割り当てられ、1, 8, 15のうち8のカウントだけが0より大きいので、ジェネレータは8のみを生成します。

• gen_1とgen_2の出力の違いは、変数array_1とarray_2に値が再割り当てされる方法によって生じるものです。

• 最初のケースでは、array_1は新しいオブジェクト[1,2,3,4,5]にバインドされ、in句は宣言時に評価されるので、古いオブジェクト[1,2,3,4]（破棄されていない）を指し続けます。

• 二つ目のケースでは、array_2へのスライス代入が古いオブジェクト[1,2,3,4]を[1,2,3,4,5]に更新します。したがって、gen_2とarray_2の両方が同じオブジェクト（現在は[1,2,3,4,5]に更新されている）を引き続き参照しています。

• では、ここまでのロジックに基づき、第3スニペットのlist(gen)の値は[11, 21, 31, 12, 22, 32, 13, 23, 33]であるべきではないでしょうか？（なぜならarray_3とarray_4はarray_1のように振る舞うはずです）。なぜ（array_4の値のみが更新されたのかは、PEP-289で解説されています。

  最も外側のfor式だけがすぐに評価され、他の式はジェネレータが実行されるまで遅延される。

💡 解説:

ジェネレータ式において、in句は宣言時に評価されますが、条件句は実行時に評価されます。

したがって、実行時になる前にarrayはリスト[2, 8, 22]に再度割り当てられ、1, 8, 15のうち8のカウントだけが0より大きいので、ジェネレータは8のみを生成します。

gen_1とgen_2の出力の違いは、変数array_1とarray_2に値が再割り当てされる方法によって生じるものです。

最初のケースでは、array_1は新しいオブジェクト[1,2,3,4,5]にバインドされ、in句は宣言時に評価されるので、古いオブジェクト[1,2,3,4]（破棄されていない）を指し続けます。

二つ目のケースでは、array_2へのスライス代入が古いオブジェクト[1,2,3,4]を[1,2,3,4,5]に更新します。したがって、gen_2とarray_2の両方が同じオブジェクト（現在は[1,2,3,4,5]に更新されている）を引き続き参照しています。

では、ここまでのロジックに基づき、第3スニペットのlist(gen)の値は[11, 21, 31, 12, 22, 32, 13, 23, 33]であるべきではないでしょうか？（なぜならarray_3とarray_4はarray_1のように振る舞うはずです）。なぜ（array_4の値のみが更新されたのかは、PEP-289で解説されています。

    最も外側のfor式だけがすぐに評価され、他の式はジェネレータが実行されるまで遅延される。

▶ is not ... は is (not ...) ではない

>>> 'something' is not None
True
>>> 'something' is (not None)
False

💡 解説:

is notは一つの二項演算子で、isとnotを分けて使うときとは動作が異なります。
is notは、オペレータの両側の変数が同じオブジェクトを指している場合はFalseに、そうでない場合はTrueに評価されます。
例では、(not None)はTrueに評価されます。なぜならNoneの値はブールコンテキストでFalseになるので、式は'something' is Trueになります。

▶ 一発でXが勝つ三目並べ！

# 行を初期化
row = [""] * 3 #行 i['', '', '']
# 盤面を作る
board = [row] * 3

出力:

>>> board
[['', '', ''], ['', '', ''], ['', '', '']]
>>> board[0]
['', '', '']
>>> board[0][0]
''
>>> board[0][0] = "X"
>>> board
[['X', '', ''], ['X', '', ''], ['X', '', '']]

"X" を3つ割り当てたわけではありませんよね？

💡 解説:

row変数を初期化すると、メモリ内で以下のようになります。

そして、rowを乗算してboardが初期化されると、メモリ内で以下のようになります（board[0], board[1], board[2]の各要素は、rowが参照している同じリストを参照）。

このシナリオを避けるには、row変数を使ってboardを生成しないようにします（このissueで尋ねられました）。

>>> board = [['']*3 for _ in range(3)]
>>> board[0][0] = "X"
>>> board
[['X', '', ''], ['', '', ''], ['', '', '']]

▶ シュレーディンガーの変数

funcs = []
results = []
for x in range(7):
    def some_func():
        return x
    funcs.append(some_func)
    results.append(some_func())  # ここで関数を呼び出していることに注意

funcs_results = [func() for func in funcs]

出力 (Pythonバージョン):

>>> results
[0, 1, 2, 3, 4, 5, 6]
>>> funcs_results
[6, 6, 6, 6, 6, 6, 6]

ループ中にsome_funcをfuncsに追加する前にxの値が毎回異なっていましたが、ループが完了した後に評価されるとすべての関数が6を返します。

>>> powers_of_x = [lambda x: x**i for i in range(10)]
>>> [f(2) for f in powers_of_x]
[512, 512, 512, 512, 512, 512, 512, 512, 512, 512]

💡 解説

• ループ内で関数を定義し、その関数の本体でループ変数を使用する場合、ループ関数のクロージャは変数にバインドされます。その値にはバインドされません。関数はその値を使用するのではなく、周囲のコンテキストからxを探します。そのため、すべての関数は計算のために変数に割り当てられた最新の値を使用します。以下、周囲のコンテキストからのxを使用していること（つまり、ローカル変数ではないこと）をご確認ください。

>>> import inspect
>>> inspect.getclosurevars(funcs[0])
ClosureVars(nonlocals={}, globals={'x': 6}, builtins={}, unbound=set())

xはグローバルな値なので、xを更新することでfuncsが参照して返す値を変更することができます。

>>> x = 42>>> [func() for func in funcs]
[42, 42, 42, 42, 42, 42, 42]

• 望ましい動作を得るためには、ループ変数を名前付き変数として関数に渡しましょう。なぜこれが機能するのか？ それは、変数を関数のスコープ内で定義するからです。もはや周囲の（グローバル）スコープを探して変数の値を探すのではなく、その時点でのxの値を格納するローカル変数を作成します。

funcs = []
for x in range(7):
    def some_func(x=x):
        return x
    funcs.append(some_func)

出力:

>>> funcs_results = [func() for func in funcs]
>>> funcs_results
[0, 1, 2, 3, 4, 5, 6]

もうグローバルスコープのxは使用していません。

>>> inspect.getclosurevars(funcs[0])
ClosureVars(nonlocals={}, globals={}, builtins={}, unbound=set())

▶ 鶏が先か卵が先か

>>> isinstance(3, int)
True
>>> isinstance(type, object)
True
>>> isinstance(object, type)
True

では、"究極"の基底クラスはどれでしょうか？それに...

>>> class A: pass>>> isinstance(A, A)
False
>>> isinstance(type, type)
True
>>> isinstance(object, object)
True

>>> issubclass(int, object)
True
>>> issubclass(type, object)
True
>>> issubclass(object, type)
False

💡 解説

• Pythonにおいてtypeはメタクラスです。
• すべてのものがPythonではオブジェクトです。クラスとそのオブジェクト（インスタンス）も含まれます。
• typeクラスはobjectクラスのメタクラスであり、typeを含むすべてのクラスは直接的にも間接的にもobjectから継承しています。
• objectとtypeの間に実際の基底クラスは存在しません。上記のスニペットでの混乱は、Pythonのクラスという観点からこれらの関係（issubclassやisinstance）を考えているからです。objectとtypeの関係は純粋なPythonでは再現できません。つまり、以下のような関係は純粋なPythonでは再現できません。
  • クラスAはクラスBのインスタンスであり、クラスBはクラスAのインスタンスである。
  • クラスAは自身のインスタンスである。
• objectとtypeのそのような関係（お互いのインスタンスでありながら自身もインスタンスである）は、実装レベルでの"ごまかし"によってPythonに存在しています。

▶ サブクラスのリレーション

出力:

>>> from collections.abc import Hashable
>>> issubclass(list, object)
True
>>> issubclass(object, Hashable)
True
>>> issubclass(list, Hashable)
False

サブクラスのリレーションは推移的であると予想されていましたよね？（AがBのサブクラスで、BがCのサブクラスならば、AもCのサブクラスであるはずです）

💡 解説:

• Pythonにおけるサブクラスのリレーションは必ずしも推移的ではありません。メタクラスで独自の任意の__subclasscheck__を定義することが許されています。
• issubclass(cls, Hashable)が呼び出されると、単にclsまたはそれが継承するものの中で偽でない"__hash__"メソッドを探します。
• objectはハッシュ可能ですが、listはハッシュ不可能なので、推移的関係が崩れます。
• より詳しい説明はこちら

▶ メソッドの等価性と同一性

class SomeClass:
    def method(self):
        pass

    @classmethod
    def classm(cls):
        pass

    @staticmethod
    def staticm():
        pass

出力:

>>> print(SomeClass.method is SomeClass.method)
True
>>> print(SomeClass.classm is SomeClass.classm)
False
>>> print(SomeClass.classm == SomeClass.classm)
True
>>> print(SomeClass.staticm is SomeClass.staticm)
True

classmに二回アクセスすると、同一ではない等価なオブジェクトが得られます。SomeClassのインスタンスでは何が起こるか見てみましょう：

o1 = SomeClass()
o2 = SomeClass()

出力:

>>> print(o1.method == o2.method)
False
>>> print(o1.method == o1.method)
True
>>> print(o1.method is o1.method)
False
>>> print(o1.classm is o1.classm)
False
>>> print(o1.classm == o1.classm == o2.classm == SomeClass.classm)
True
>>> print(o1.staticm is o1.staticm is o2.staticm is SomeClass.staticm)
True

SomeClassの同じインスタンスに対してclassmやmethodに二回アクセスすると、等価ではあるが同一ではないオブジェクトが生成されます。

💡 解説:

• 関数はデスクリプタです。属性として関数にアクセスするときはいつでも、デスクリプタが呼び出され、属性を所有するオブジェクトと関数を「バインド」するメソッドオブジェクトが作成されます。呼び出された場合、メソッドは関数を呼び出し、暗黙のうちにバインドされたオブジェクトを最初の引数として渡します（これが、明示的に渡さなくてもselfが最初の引数として得られる方法です）。

>>> o1.method
<bound method SomeClass.method of <__main__.SomeClass object at ...>>

• 属性に複数回アクセスすると、毎回メソッドオブジェクトが作成されます！したがって、o1.method is o1.method が真になることはありません。インスタンスではなくクラス属性として関数にアクセスするとメソッドは作成されないので、SomeClass.method is SomeClass.method は真です。

>>> SomeClass.method
<function SomeClass.method at ...>

• classmethod は関数をクラスメソッドに変換します。クラスメソッドはデスクリプタであり、アクセスされると、オブジェクト自体ではなくオブジェクトのクラス（型）をバインドするメソッドオブジェクトを作成します。

>>> o1.classm
<bound method SomeClass.classm of <class '__main__.SomeClass'>>

• 関数とは異なり、classmethodはクラス属性としてアクセスされた場合にもメソッドを作成します（この場合、それはクラスにバインドされ、型にはバインドされません）。したがってSomeClass.classm is SomeClass.classmは偽です。

>>> SomeClass.classm
<bound method SomeClass.classm of <class '__main__.SomeClass'>>

• メソッドオブジェクトは、関数が等しく、バインドされたオブジェクトが同じである場合に等しくなります。したがって、o1.method == o1.methodは真ですが、メモリ上で同じオブジェクトではありません。
• staticmethodは関数をそのまま返す「ノーオペレーション」のディスクリプタに変換します。メソッドオブジェクトは一切作成されないので、isでの比較は真となります。

>>> o1.staticm
<function SomeClass.staticm at ...>
>>> SomeClass.staticm
<function SomeClass.staticm at ...>

• インスタンスメソッドを呼び出すたびに新しい「メソッド」オブジェクトを作成し、selfを挿入するために毎回引数を変更する必要があるため、パフォーマンスに悪影響を及ぼしました。
  CPython 3.7は、一時的なメソッドオブジェクトを作成せずにメソッドを呼び出す新しいオペコードを導入することで、これを解決しました。これはアクセスされた関数が実際に呼び出されるときのみ使用されるので、この例のスニペットは影響を受けず、依然としてメソッドを生成します :)

▶ すべて真である

>>> all([True, True, True])
True
>>> all([True, True, False])
False

>>> all([])
True
>>> all([[]])
False
>>> all([[[]]])
True

このTrue-Falseはなぜ交互になるのでしょうか？

💡 解説:

• all関数の実装は以下のように等価です。

  def all(iterable): for element in iterable: if not element: return False return True
  
  

• all([])はiterableが空であるためTrueを返します。

• all([[]])はFalseを返します。なぜなら渡された配列には[]という一つの要素があり、Pythonでは空のリストは偽と評価されるからです。

• all([[[]]])とそれ以上の再帰的なバリアントは常にTrueです。これは渡された配列の単一の要素（[[...]]）がもはや空ではなく、値があるリストは真と評価されるからです。

▶ 驚きのコンマ

出力 (< 3.6):

>>> def f(x, y,):
...     print(x, y)
...
>>> def g(x=4, y=5,):
...     print(x, y)
...
>>> def h(x, **kwargs,):
  File "<stdin>", line 1
    def h(x, **kwargs,):
                     ^
SyntaxError: invalid syntax

>>> def h(*args,):
  File "<stdin>", line 1
    def h(*args,):
                ^
SyntaxError: invalid syntax

💡 説明

• トレーリングコンマ（末尾のコンマ）は、Python関数の形式パラメータリストにおいて常に使えるわけではありません。
• Pythonでは、引数リストは先行するコンマと後続するコンマの一部で定義されています。この対立が原因で、コンマが中間に挟まれ、どのルールにも適合しない状況が生じます。
• 注意: トレーリングコンマの問題はPython 3.6で修正されています。この投稿のコメント欄でPythonにおけるトレーリングコンマのさまざまな使用法についても簡単な議論がされています。

▶ 文字列とバックスラッシュ

出力:

>>> print("\"")
"

>>> print(r"\"")
\"

>>> print(r"\")
File "<stdin>", line 1
    print(r"\")
              ^
SyntaxError: 文字列リテラル中での行末

>>> r'\'' == "\\'"
True

💡 解説:

• 通常のPython文字列では、バックスラッシュは特別な意味を持つ文字（シングルクォート、ダブルクォート、バックスラッシュ自体など）をエスケープするために使用されます。

  >>> "wt\"f"
  'wt"f'
  

バックスラッシュに続く文字をエスケープするという動作とともに、バックスラッシュ自体もそのまま渡されます。

>>> r'wt\"f' == 'wt\\"f'
True
>>> print(repr(r'wt\"f')
'wt\\"f'

>>> print("\n")

>>> print(r"\\n")
'\\n'

• パーサーが生の文字列リテラル（rプレフィックスで示される）でバックスラッシュ（\）に遭遇すると、何らかの文字を続けることを期待します。そして、このケース（print(r"\")）では、バックスラッシュが末尾の引用符をエスケープし、パーサーを終了引用符なしにしてしまったため、SyntaxErrorが発生しています。そのため、raw文字列の末尾にバックスラッシュを使用することはできません。

▶ notの結び目

x = True
y = False

出力:

>>> not x == y
True
>>> x == not y
  File "<input>", line 1
    x == not y
           ^
SyntaxError: invalid syntax

💡 解説:

• 演算子の優先順位は式がどのように評価されるかに影響を与えます。Pythonでは、== 演算子は not 演算子よりも優先順位が高いです。
• したがって not x == y は not (x == y) と同等であり、これは最終的に not (True == False) と評価され True になります。
• しかし x == not y は SyntaxError を引き起こします。これは (x == not) y と同等であり、最初に予想された x == (not y) ではないからです。
• パーサーは not トークンを not in 演算子の一部として期待していました（なぜなら == と not in 演算子は同じ優先順位を持っているため）。しかし、not トークンの後に in トークンを見つけられなかったため、SyntaxError を発生させました。

▶ 半分のトリプルクォート文字列

出力:

>>> print('wtfpython''')
wtfpython
>>> print("wtfpython""")
wtfpython
>>> # 以下のステートメントは `SyntaxError` を発生させる
>>> # print('''wtfpython')
>>> # print("""wtfpython")
  File "<input>", line 3
    print("""wtfpython")
                        ^
SyntaxError: EOF while scanning triple-quoted string literal

💡 解説:

• Pythonは暗黙的な文字列リテラルの連結をサポートしています。例えば、

  >>> print("wtf" "python")
  wtfpython
  >>> print("wtf" "") # または "wtf"""
  wtf
  

• ''' と """ もPythonで文字列区切りとして使用されるため、Pythonインタプリタは現在出会っているトリプルクォート文字列リテラルの終わりとしてトリプルクォートの区切りを期待しているため、SyntaxError が発生します。

▶ ブール値の意外な挙動

# iterableに含まれるブール値と整数の数を数えるシンプルな例。
mixed_list = [False, 1.0, "some_string", 3, True, [], False]
integers_found_so_far = 0
booleans_found_so_far = 0

for item in mixed_list:
    if isinstance(item, int):
        integers_found_so_far += 1
    elif isinstance(item, bool):
        booleans_found_so_far += 1

出力:

>>> integers_found_so_far
4
>>> booleans_found_so_far
0

>>> some_bool = True
>>> "wtf" * some_bool
'wtf'
>>> some_bool = False
>>> "wtf" * some_bool
''

def tell_truth():
    True = False
    if True == False:
        print("I have lost faith in truth!")

出力 (< 3.x):

>>> tell_truth()
I have lost faith in truth!

💡 説明:

• Pythonにおける bool は int のサブクラスです

  >>> issubclass(bool, int)
  True
  >>> issubclass(int, bool)
  False
  

そのため、True と False は int のインスタンスです。

>>> isinstance(True, int)
True
>>> isinstance(False, int)
True

True の整数値は 1 で、False の整数値は 0 です。

>>> int(True)
1
>>> int(False)
0

• 詳細な理由については、このStackOverflowの回答をご参照ください。
• 元々Pythonには bool 型がなく（偽を表すには 0 を、真を表すには 1 のような非ゼロ値を使用していました）、True、False、そして bool 型が 2.x バージョンで追加されましたが、後方互換性のために True と False を定数にすることはできませんでした。それらは単なるビルトイン変数で、再割り当てが可能でした。
• Python 3 は後方互換性がなかったので、ついにこの問題が修正され、したがって最後のスニペットは Python 3.x では動作しません！

▶ クラス属性とインスタンス属性

class A:
    x = 1

class B(A):
    pass

class C(A):
    pass

出力:

>>> A.x, B.x, C.x
(1, 1, 1)
>>> B.x = 2
>>> A.x, B.x, C.x
(1, 2, 1)
>>> A.x = 3
>>> A.x, B.x, C.x # C.xは変わったが、B.xは変わらなかった
(3, 2, 3)
>>> a = A()
>>> a.x, A.x
(3, 3)
>>> a.x += 1
>>> a.x, A.x
(4, 3)

class SomeClass:
    some_var = 15
    some_list = [5]
    another_list = [5]
    def __init__(self, x):
        self.some_var = x + 1
        self.some_list = self.some_list + [x]
        self.another_list += [x]

出力:

>>> some_obj = SomeClass(420)
>>> some_obj.some_list
[5, 420]
>>> some_obj.another_list
[5, 420]
>>> another_obj = SomeClass(111)
>>> another_obj.some_list
[5, 111]
>>> another_obj.another_list
[5, 420, 111]
>>> another_obj.another_list is SomeClass.another_list
True
>>> another_obj.another_list is some_obj.another_list
True

💡 解説

• クラス変数とクラスインスタンスの変数は、クラスオブジェクトの辞書として内部的に扱われます。変数名が現在のクラスの辞書に見つからない場合は、親クラスが検索されます。
• += 演算子は、新しいオブジェクトを作成せずに変更可能なオブジェクトをその場で変更します。したがって、あるインスタンスの属性を変更すると、他のインスタンスとクラス属性にも影響が及びます。

▶ Noneの生成

some_iterable = ('a', 'b')

def some_func(val):
    return "something

出力 (<= 3.7.x):

>>> [x for x in some_iterable]
['a', 'b']
>>> [(yield x) for x in some_iterable]
<generator object <listcomp> at 0x7f70b0a4ad58>
>>> list([(yield x) for x in some_iterable])
['a', 'b']
>>> list((yield x) for x in some_iterable)
['a', None, 'b', None]
>>> list(some_func((yield x)) for x in some_iterable)
['a', 'something', 'b', 'something']

💡 解説:

• これは、ジェネレータと包括的な理解での yield のCPythonの扱いに関するバグです。
• ソースと詳しい解説はこちら
• 関連するバグレポート: https://bugs.python.org/issue10544
• Python 3.8+ では、リスト内包表記で yield を使用することは許可されておらず、SyntaxError が投げられます。

▶ returnからyield

def some_func(x):
    if x == 3:
        return ["wtf"]
    else:
        yield from range(x)

出力 (> 3.3):

>>> list(some_func(3))
[]

"wtf"はどこに消えたのでしょうか？これはyield fromの特別な効果によるものでしょうか？検証してみましょう。

def some_func(x):
    if x == 3:
        return ["wtf"]
    else:
        for i in range(x):
          yield i

出力:

>>> list(some_func(3))
[]

同じ結果です。機能しませんでした。

💡 解説:

• Python 3.3以降、ジェネレータ内で値を伴うreturnステートメントを使用することが可能になりました（PEP380を参照）。公式ドキュメントでは、

"... ジェネレータの中でreturn exprを使用すると、ジェネレータの終了時にStopIteration(expr)が発生する。"

とあります。

• some_func(3)のケースでは、returnステートメントのためにStopIterationが発生し、最初にリストが空になります。StopIteration例外は、list(...)ラッパーやforループ内で自動的にキャッチされます。したがって、上記の2つのスニペットは空のリストになります。
• ジェネレータsome_funcから["wtf"]を取得するには、StopIteration例外をキャッチする必要があります。

try:
    next(some_func(3))
except StopIteration as e:
    some_string = e.valu

• >>> some_string ["wtf"]

▶ Nanの再帰性

a = float('inf')
b = float('nan')
c = float('-iNf')  # 大文字小文字は区別しません
d = float('nan')

出力:

>>> a
inf
>>> b
nan
>>> c
-inf
>>> float('some_other_string')
ValueError: could not convert string to float: some_other_string
>>> a == -c # inf==inf
True
>>> None == None # None == None
True
>>> b == d # but nan!=nan
False
>>> 50 / a
0.0
>>> a / a
nan
>>> 23 + b
nan

>>> x = float('nan')
>>> y = x / x
>>> y is y # 同一性は保持
True
>>> y == y # yの等価性は失敗
False
>>> [y] == [y] # だがyを含むリストの等価性は成功
True

💡 解説:

• 'inf'と'nan'は特別な文字列（大文字小文字を区別しない）で、明示的にfloat型にキャストすると、それぞれ数学的な"無限"と"非数"を表すために使用されます。
• IEEE標準によるとNaN != NaNなので、このルールに従うと、Pythonのコレクション要素の反射性の仮定が破られます。つまり、xがlistのようなコレクションの一部である場合、比較のような実装はx == xという仮定に基づいています。この仮定により、まず同一性が比較されます（速度が速いため）。値は同一性が不一致の場合にのみ比較されます。以下のスニペットでより明確に理解できるでしょう。

>>> x = float('nan')
>>> x == x, [x] == [x]
(False, True)
>>> y = float('nan')
>>> y == y, [y] == [y]
(False, True)
>>> x == y, [x] == [y]
(False, False

• xとyの同一性が異なるため、値が考慮され、これらも異なるため、比較は今回Falseを返します。
• 参考: Reflexivity, and other pillars of civilization

▶ 不変の変異

Pythonの参照の仕組みを知っていれば、これは些細なことかもしれません。

some_tuple = ("A", "tuple", "with", "values")
another_tuple = ([1, 2], [3, 4], [5, 6])

出力:

>>> some_tuple[2] = "change this"
TypeError: 'tuple' object does not support item assignment
>>> another_tuple[2].append(1000) #これはエラーを投げない
>>> another_tuple
([1, 2], [3, 4], [5, 6, 1000])
>>> another_tuple[2] += [99, 999]
TypeError: 'tuple' object does not support item assignment
>>> another_tuple
([1, 2], [3, 4], [5, 6, 1000, 99, 999])

あれ？tupleは不変だったのでは？

💡 解説:

• https://docs.python.org/3/reference/datamodel.html からの引用

  不変のシーケンス
  不変のシーケンス型のオブジェクトは、一度作成されると変更することはできません。（オブジェクトが他のオブジェクトへの参照を含んでいる場合、これらの他のオブジェクトは変更可能であり変更されることがあります。しかし、不変オブジェクトが直接参照するオブジェクトの集合は変更することができません。）

• += 演算子は新しいオブジェクトを作成せずに、変更可能なオブジェクトをその場で変更します。アイテムの代入は機能しませんが、例外が発生したときには、アイテムはすでにその場で変更されています。

• Pythonの公式 FAQにも説明があります。

▶ 外部スコープから消える変数

e = 7
try:
    raise Exception()
except Exception as e:
    pass

出力 (Python 2.x):

>>> print(e)
# 何も表示されない

出力 (Python 3.x):

>>> print(e)
NameError: name 'e' is not defined

💡 解説:

• 出典: https://docs.python.org/3/reference/compound_stmts.html#except

  as ターゲットを使って例外が割り当てられた場合、except 節の終わりでクリアされます。まるで

  except E as N:
      foo
  

が以下に変換されたかのようです。

except E as N:
    try:
        foo
    finally:
        del N

• これは、例外をexcept節の後でも参照するためには、例外を別の名前に割り当てる必要があることを意味します。例外は、トレースバックが添付されているため、スタックフレームと参照サイクルを形成し、次のガベージコレクションが行われるまでそのフレーム内のすべてのローカル変数を生き続けさせます。
• Pythonでは節にスコープがありません。例の中の全てが同じスコープ内に存在し、変数eはexcept節の実行によって除去されました。これは、それぞれの内部スコープを持つ関数では当てはまりません。以下の例がこれを分かりやすく表しています：

def f(x):
    del(x)
    print(x)

x = 5
y = [5, 4, 3]

出力:

>>> f(x)
UnboundLocalError: local variable 'x' referenced before assignment
>>> f(y)
UnboundLocalError: local variable 'x' referenced before assignment
>>> x
5
>>> y
[5, 4, 3]

Python 2.xでは、変数名eはException()インスタンスに割り当てられるので、printしようとしても何も表示されません。

出力 (Python 2.x):

>>> e
Exception()
>>> print e
# 何も表示されない！

▶ 謎のキー型変換

class SomeClass(str):
    pass

some_dict = {'s': 42}

出力:

>>> type(list(some_dict.keys())[0])
str
>>> s = SomeClass('s')
>>> some_dict[s] = 40>>> some_dict # 2つの異なるキー値ペアが期待される
{'s': 40}
>>> type(list(some_dict.keys())[0])
str

💡 解説:

• オブジェクト s と文字列 "s" は同じ値にハッシュされます。なぜなら SomeClass は str クラスの __hash__ メソッドを継承しているからです。

• SomeClass("s") == "s" は True に評価されます。なぜなら SomeClass は str クラスから __eq__ メソッドも継承しているからです。

• 両方のオブジェクトが同じ値にハッシュされ、等しいため、辞書内で同じキーで表されます。

• 望ましい動作を得るためには、SomeClass 内で __eq__ メソッドを再定義することができます。

  class SomeClass(str):
    def __eq__(self, other):
        return (
            type(self) is SomeClass
            and type(other) is SomeClass
            and super().__eq__(other)
        )
  
  # カスタムの __eq__ を定義すると、Pythonは自動的に __hash__ メソッドを継承しなくなるため、 # それも定義する必要がある __hash__ = str.__hash__
  some_dict = {'s':42}
  

出力:

>>> s = SomeClass('s')
>>> some_dict[s] = 40>>> some_dict
{'s': 40, 's': 42}
>>> keys = list(some_dict.keys())
>>> type(keys[0]), type(keys[1])
(__main__.SomeClass, str)

▶ これは分かるかな？

a, b = a[b] = {}, 5

出力:

>>> a
{5: ({...}, 5)}

💡 解説

Python language referenceによると、代入文は以下の形をとります。

  ```python
  (target_list "=")+ (expression_list | yield_expression)
  ```

そして以下のようになります。

• 代入文は式リストを評価し（これは単一の式か、カンマで区切られたリストであり、後者はタプルを生成します）、得られた単一のオブジェクトは左から右に各ターゲットリストに割り当てられます。

• (target_list "=")+ の + は 1つ以上の ターゲットリストがあることを意味します。この場合のターゲットリストは a, b と a[b] です（式リストは1つだけで、この場合は {}, 5 です）。

• 式リストが評価された後、その値は 左から右 へターゲットリストにアンパックされます。したがって、このケースでは、最初に {}, 5 のタプルが a, b にアンパックされ、a = {} と b = 5 になります。

• a は {} に割り当てられます。これは変更可能なオブジェクトです。

• 2つ目のターゲットリストは a[b] です（この時点で a と b が前の文で定義されていないため、エラーが発生すると考えるかもしれませんが、覚えておいてください、私たちはちょうど a を {} に、b を 5 に割り当てました）。

• ここで、辞書のキー 5 にタプル ({}, 5) を設定し、循環参照を作成します（出力の {...} は a が既に参照している同じオブジェクトを指します）。循環参照の別の簡単な例は以下の通りです。

• の通りです。

  >>> some_list = some_list[0] = [0]
  >>> some_list
  [[...]]
  >>> some_list[0]
  [[...]]
  >>> some_list is some_list[0]
  True
  >>> some_list[0][0][0][0][0][0] == some_list
  True
  

• この例でも同様です（a[b][0] は a と同じオブジェクトです）。

• まとめると、このように噛み砕くことができます。

  a, b = {}, 5
  a[b] = a, b
  

そして、循環参照は a[b][0] が a と同じオブジェクトであるという事実によって正当化されます。

>>> a[b][0] is a
True

▶ 整数文字列変換が限界を超えるとき

>>> # Python 3.10.6
>>> int("2" * 5432)

>>> # Python 3.10.8
>>> int("2" * 5432)

出力:

>>> # Python 3.10.6
222222222222222222222222222222222222222222222222222222222222222...

>>> # Python 3.10.8
Traceback (most recent call last):
   ...
ValueError: Exceeds the limit (4300) for integer string conversion:
   value has 5432 digits; use sys.set_int_max_str_digits()
   to increase the limit.

💡 解説:

この int() の呼び出しはPython 3.10.6では問題なく動作し、Python 3.10.8では ValueError を引き起こします。Pythonは依然として大きな整数を扱うことができますが、このエラーは整数と文字列の間で変換するときにのみ発生します。

幸いにも、予想される操作がその限界を超える場合、許可される桁数の限界を増やすことができます。これを行うために、以下のいずれかを使用できます：

• コマンドラインフラグ X int_max_str_digits
• sys モジュールからの set_int_max_str_digits() 関数
• 環境変数 PYTHONINTMAXSTRDIGITS

この値を超えることが予想されるコードについて、デフォルトの限界を変更する詳細については、こちらを参照。