Mikhail V writes: > But how do you jump to lists already?
Because "+" and "+=" are operators which may be defined for any objects. Paul explained *why* he chose to to do that elsewhere. My point is that the semantics "a += b" *is* "type(a).__iadd__(a, b)" is true for all objects. It is a fundamental consistency in Python. It may make what one might consider odd behavior fall into its proper place. Thus, in explaining this kind of thing it is often useful (YMMV) to "jump" to a different type that supports the same behavior to see how a proposed change can cause inconsistency. > I started an example with integers. I just want to increment an > integer and I don't want to see any += in my code, it strains > me. If you *really* want to limit this to *integers* in *your* code, that's easy enough. Just don't use it. If by "my code" you mean "code I might have to read"[1], you're just out of luck, even for the very special case of integers. (1) Guido himself preferred *not* to have augmented assignment way back when, but bowed to popular demand. You are in a tiny minority, opposing the preference of a large and loud majority. (2) Guido could remove those operators, but it would break a lot of existing code that uses them, and that would not be acceptable.[2] (3) It would be a gratuitous special case, a fundamental inconsistency in Python semantics. So it's not just calming down. You need to understand that if you want to use a popular language with batteries included and a huge range of battle-tested very useful add-ons, you're going to have to accept that you will often be reading code that you would refuse to write unless forced to by court order. You see, you're wasting your own time here by trying to explain. It's just your preference, which in this matter is as valid as any other *so no explanation is necessary*. But the opinion that "+=" for integers is useful and readable was the majority when it was installed, and backward compability rules out changing it now. And I really don't think you have to worry about "=+". Footnotes: [1] And IMHO it is Pythonic to interpret "in my code" that way. Ie, it is Pythonic to be readable to as many Python developers as possible. But it would smooth discussion to distinguish the "my code" that you *write* from the "my code" that you *read* in your posts. (I guess English is a second language for you, it may not be worth it and *we* will adapt. But it does help, if you would like to try.) [2] Theoretically, he has the power. But he also has promised no such backward incompatible changes "ever again", so practically impossible. Yes, IMO this would be a breaking change big enough to compare to Unicode in 3.0. _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
