Python を知らない人には >>357 はワケワカメだと思うので補足しとく

変数への破壊的代入を基本とする大半の手続き型言語、例えば Ruby や JavaScript、
さらには古典的な Pascal や C において、スコープは以下のように定義される：
　(1) あるスコープの内側で宣言された変数は、スコープの外側にあるコードから読み書きできない
　(2) あらゆるスコープの内側のコードは外側の変数を自由に読み書きできる

ところが Python という言語だけは、ナゼか (2) をオレ様定義した
　(2)’ あらゆるスコープの内側のコードは外側の変数を自由に読めるが、書き込みはできない

まあそんなオレ様定義も設計哲学やら個性と見れば批判にはならないのだけれど、
>>375 で実際のコードを使って示したように、このオレ様定義が実装されたのは
数値や文字列といった単純型だけで、配列/集合/辞書およびユーザ定義クラスといった
複合データ型では実装を忘れたものだから、何のためのオレ様定義だったの？と批判されている

おまけにこのスコープ問題を解決するために世の中の常識的なスコープ定義へ訂正するという
根本策を採用せず、わざわざ予約語 nonlocal やら grobal を消費してまで変数宣言文という構文を
追加するといふ「行き当たりばったりで適当な泥縄実装」を Python3 でやらかしたものだから、
>>354氏が指摘したように「スコープがぐちゃぐちゃ」になったわけです

このスコープ問題もラムダ式問題(>>303 の (3))と同様に Python4 で修正されて
「後方互換性の断絶」が再現されるんでしょうね