我认为这与对象的可变性和不变性的概念有关。2,3,4,5在python中是不可变的。参考下图。2在此python进程之前有固定的id。

x++本质上意味着像C一样的原地增量。在C中，x++执行原地增量。因此，x=3, x++会将内存中的3增加到4，不像python中的3仍然存在于内存中。

因此，在python中，你不需要在内存中重新创建一个值。这可能会导致性能优化。

这是一个基于直觉的答案。

我对python为什么没有++操作符的理解如下:当你用python写这个时，a=b=c=1，你会得到三个变量(标签)指向同一个对象(值为1)。你可以使用id函数来验证这一点，它将返回一个对象内存地址:

In [19]: id(a)
Out[19]: 34019256

In [20]: id(b)
Out[20]: 34019256

In [21]: id(c)
Out[21]: 34019256

所有三个变量(标签)都指向同一个对象。现在增加变量之一，看看它是如何影响内存地址的:

In [22] a = a + 1

In [23]: id(a)
Out[23]: 34019232

In [24]: id(b)
Out[24]: 34019256

In [25]: id(c)
Out[25]: 34019256

你可以看到变量a现在指向另一个对象，变量b和c。因为你已经使用了a = a + 1，这是明确的。换句话说，你将完全另一个对象赋值给标签a。想象一下，你可以写一个++，这将表明你没有给变量赋值一个新对象，而是给旧对象赋值。所有这些东西都是为了尽量减少混淆。为了更好地理解python变量是如何工作的:

在Python中，为什么函数可以修改调用者感知到的一些参数，而不能修改其他参数?

Python是按值调用还是按引用调用?既不。

Python是按值传递还是按引用传递?

Python是按引用传递还是按值传递?

如何通过引用传递变量?

理解Python变量和内存管理

在python中模拟值传递行为

Python函数通过引用调用

像Pythonista一样编写代码:地道的Python

其他答案描述了为什么迭代器不需要它，但有时它在赋值以inline增加变量时很有用，你可以使用元组和多次赋值达到相同的效果:

B = ++a变成:

a,b = (a+1,)*2

b = a++变成:

a,b = a+1, a

Python 3.8引入了赋值:=操作符，允许我们用

foo(a:=a+1)

Foo (a++)仍然是难以捉摸的。

操作符的++类是带有副作用的表达式。这在Python中通常是找不到的。

出于同样的原因，赋值在Python中不是表达式，从而防止使用here */}习语来使用常见的if (a = f(…)){/*。

最后，我怀疑这些操作符与python的引用语义不太一致。请记住，Python没有C/ c++中已知语义的变量(或指针)。

正如我理解的那样，你不会认为内存中的值被改变了。 在c语言中，当你执行x++时，内存中的x值会发生变化。 但在python中，所有数字都是不可变的，因此x指向的地址仍然是x而不是x+1。当你写x++时，你会认为x改变了，实际上发生的是x引用被改变到内存中存储x+1的位置，或者如果doe不存在，重新创建这个位置。

Maybe a better question would be to ask why do these operators exist in C. K&R calls increment and decrement operators 'unusual' (Section 2.8page 46). The Introduction calls them 'more concise and often more efficient'. I suspect that the fact that these operations always come up in pointer manipulation also has played a part in their introduction. In Python it has been probably decided that it made no sense to try to optimise increments (in fact I just did a test in C, and it seems that the gcc-generated assembly uses addl instead of incl in both cases) and there is no pointer arithmetic; so it would have been just One More Way to Do It and we know Python loathes that.