Pythonについて私が尊敬していることの1つは、可変型と不変型の違いです。Pythonに来る前にcでプログラミングをしていたので、Pythonがcで私を怒らせるポインター逆参照のすべての複雑さを簡単に取り除くことができることに驚きました。Pythonでは、すべてが期待どおりに機能し、可変/不変の区別がその中で重要な役割を果たしていることにすぐに気付きました。
もちろん、まだいくつかのしわがあります（可変関数の引数のデフォルトが注目に値する例です）が、全体として、可変/不変の区別は、変数とその値が何であるか、およびそれらがどのように動作するかという問題を大いに明確にすると思います。
しかし、それはどこから来たのでしょうか？私は、GvRがこの区別を思いついた最初の人ではなく、Pythonがそれを使用した最初の言語ではなかったと仮定する必要があります。私は、この概念を使用した初期の言語と、それに関する初期の理論的議論について聞くことに興味があります。
不変性のアイデアが好きなら、純粋な関数型言語をチェックする必要があります。Haskellでは、すべての（純粋な）変数は不変です（まだ「変数」と呼ばれていますが、そこにあります）。これは素晴らしいアイデアです。関数に何かを渡しても、それを変更することはできないことを、あなたとコンパイラの両方が知っています。
Cでは、言語がコピーセマンティクスに基づいているため、不変の明示的な概念はありません。代わりにPythonでは、値は常に参照によって渡され、不変性は言語を管理しやすくするために重要な役割を果たします。
Pythonでは、すべてが実際にポインターであるため、ポインターはありません。偶数のオブジェクトが時間の経過とともに値を変更する可能性があるというPythonプログラムの意味を想像してみてください...あなたは次のようなトリックをプレイすることを余儀なくされます
class Shape:
def __init__(self, points):
self.points = points[:] # make a copy of the list
not only for lists and dicts, but also for numeric values and strings.
So basically in Python some types have immutable instances because they normally are used as "values" and you don't care about identity. In the rare cases in which you need for example a mutable object with a numeric value you need to explicitly wrap it up in say a class instance.
In other languages substantially based on reference semantic like LISP immutability is a choice left to the programmer and not a constraint even if many functions and idioms are supporting it (a big percentage of LISP standard library functions are non-destructive and it's indeed sort of a shame that destructive ones aren't always clearly distinguishable by the name).
So for example strings are mutable LISP but probably not many LISP programs actually modify strings in place because that would mean giving up the nice possibility of sharing and would require explicitly copying strings in many places (in most cases strings are just values, not objects in which you care about identity). Are strings immutable in LISP? No. Are programs mutating them? Almost never.
Not leaving a choice to the programmer is in the spirit of the Python language. It feels great when the choices you are forced to are in line with your idea... less decisions and things are exactly like you wanted them to be.
There are however in my opinion two different dangers with this approach:
Problems arise when those pre-made choices are NOT in line on what you would like or need to do. Python is a wonderful language, but with a different dictator could become pure hell.
Understanding and making choiches forces you to think and expands your mind. Not making choices instead just puts a cage on your mind and after a while you may not even realize that what you are using is just ONE possibility, not the only possibility. After a while you may begin to just think that "things MUST be done this way": you don't even feel you are forced because your mind has already been "mutilated".
Objective Cには、可変/不変の区別がロードされています（たとえば、NSStringとの両方が存在する点まで）。NSMutableStringPythonより約8年前のものです。Objective Cがオブジェクト指向設計の多くを継承したSmalltalkは、この概念をあまり使用していません（特に、文字列は不変ではありません。最近の傾向は、Python、Rubyなどのように不変の文字列に向かっています）。
ウィキペディアから次のエントリを読むことをお勧めします。