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

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

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

这可能是因为@GlennMaynard将这个问题与其他语言进行了比较，但在Python中，你用Python的方式做事。这不是一个“为什么”的问题。它在这里，你可以用x+=做同样的事情。在Python的禅宗中，它被赋予:“应该只有一种方法来解决一个问题。”多重选择在艺术上很好(表达自由)，但在工程上很糟糕。

这并不是因为它没有意义;将“x++”定义为“x+ = 1，求值到x的前一个绑定”非常有意义。

如果你想知道最初的原因，你必须在旧的Python邮件列表中寻找，或者询问当时在那里的人(例如。Guido)，但事后很容易就能证明:

简单的递增和递减不需要像其他语言那样多。你不会写这样的for(int i = 0;I < 10;i)在Python中经常使用;相反，你可以把I放在(0,10)范围内。

由于不经常需要它，所以没有理由给它自己的特殊语法;当您确实需要增加时，+=通常就可以了。

It's not a decision of whether it makes sense, or whether it can be done--it does, and it can. It's a question of whether the benefit is worth adding to the core syntax of the language. Remember, this is four operators--postinc, postdec, preinc, predec, and each of these would need to have its own class overloads; they all need to be specified, and tested; it would add opcodes to the language (implying a larger, and therefore slower, VM engine); every class that supports a logical increment would need to implement them (on top of += and -=).

这些都是+=和-=的冗余，所以会变成净损失。

当然，我们可以说“Guido只是决定那样做”，但我认为问题实际上是关于这个决定的原因。我认为有以下几个原因:

它将语句和表达式混合在一起，这不是好的实践。参见http://norvig.com/python-iaq.html 它通常鼓励人们编写可读性较差的代码 语言实现中的额外复杂性，如前所述，这在Python中是不必要的

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

因为，在Python中，整数是不可变的(int's +=实际上返回一个不同的对象)。

同样，使用++/——，您需要考虑前后的递增/递减，并且只需要多击一次键就可以写出x+=1。换句话说，它以很少的收益为代价避免了潜在的混乱。