Why there are no ++/-- operators in Python?
+1
A:
That's just how python was designed, no point complaining.
Alexander Rafferty
2010-09-06 23:35:12
Not complaining, rather trying to understand the reasoning :)
Leonid
2010-09-06 23:43:32
-1; this answer doesn't explain why, which is what the question is asking.
RCIX
2010-09-08 01:28:39
+5
A:
It was just designed that way. Increment and decrement operators are just shortcuts for x = x + 1. Python has typically adopted a design strategy which reduces the number of alternative means of performing an operation. Augmented assignment is the closest thing to increment/decrement operators in Python, and they weren't even added until Python 2.0.
Reed Copsey
2010-09-06 23:37:27
+22
A:
It's not because it doesn't make sense; it makes perfect sense to define "x++" as "x += 1, evaluating to the previous binding of x".
If you want to know the original reason, you'll have to either wade through old Python mailing lists or ask somebody who was there (eg. Guido), but it's easy enough to justify after the fact:
Simple increment and decrement aren't needed as much as in other languages. You don't write things like for(int i = 0; i < 10; ++i) in Python very often; instead you do things like for i in range(0, 10).
Since it's not needed nearly as often, there's much less reason to give it its own special syntax; when you do need to increment, += is usually just fine.
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 -=).
This is all redundant with += and -=, so it would become a net loss.
Glenn Maynard
2010-09-06 23:57:42
`x++` is not the same as `x=x+1` in C! When x and y are references to the same int, `x++` changes both. `x=x+1` in Python changes only x. The reason is that only makes sense with variables, little boxes where you put stuff in and `++` changes the content of the box. Python doesn't have variables, so you can't do this like in C (without fully mutable ints).
THC4k
2010-09-07 01:03:54
@THC4k: Nobody's talking about a post-increment operator that's in every way equivalent to C's, because the languages differ at fundamental levels. Yes, there are other consistency issues that you would run up against if you tried to shoehorn these operators into Python at this point in its development. Also, it's plainly ludicrous to claim that Python doesn't have variables; please don't play word games that will confuse poor, impressionable newcomers. A variable in Python is essentially a name, not a memory location as in C, but it's still a variable.
Glenn Maynard
2010-09-07 01:58:42
@THC4k: Why do you think ++ and -- would only work with ints? Whether ints are mutable is completely orthogonal to this discussion.
Nick Bastin
2010-09-07 05:23:14
@Glenn Maynard: I find it more confusing to use "variables" and "references" with things that don't behave as in C or Java. Exactly *because* Python and C differ at a fundamental level you can't have a `++` that behaves as in C, without changing the language completely - ie by adding references or by boxing all numbers. But instead of pointing that out, you just say "`x=x+1` is what you're looking for, but it's not that useful anyways". That is a *rationalization*, not a *technical explanation*.
THC4k
2010-09-07 12:38:28
@THC4k: "Variables" is not a C term, it's a general programming term; if you find its use in Python to be confusing, that's your own confusion at work. You could obviously define `x++` in Python as an expression which rebinds `x` with the value of `x.__postinc__()` and resolves to a reference to the previous binding of `x`. But you're not actually interested in *technical explanations*, you're just looking for things to put in *italics*, and you don't actually seem to *have any point*.
Glenn Maynard
2010-09-07 19:58:44
+7
A:
The C increment/decrement operators were invented at a time when the C compiler wasn't very smart and the authors wanted to be able to specify the direct intent that a machine language operator should be used which saved a handful of cycles for a compiler which might do a
load memory
load 1
add
store memory
instead of
inc memory
and the PDP-11 even supported "autoincrement" and "autoincrement deferred" instructions corresponding to *++p and *p++, respectively. See section 5.3 of the manual if horribly curious.
As compilers are smart enough to handle the high-level optimization tricks built into the syntax of C, they are just a syntactic convenience now.
Python doesn't have tricks to convey intentions to the assembler because it doesn't use one.
msw
2010-09-07 00:08:29
+2
A:
I'm very new to python but I suspect the reason is because of the emphasis between mutable and immutable objects within the language. Now, I know that x++ can easily be interpreted as x = x + 1, but it LOOKS like you're incrementing in-place an object which could be immutable.
Just my guess/feeling/hunch.
mkoistinen
2010-09-07 00:11:00
A:
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.
Ludovico Fischer
2010-09-07 00:11:43
+1
A:
Because, in Python, integers are immutable (int's += actually returns a different object).
Also, with ++/-- you need to worry about pre- versus post- increment/decrement, and it takes only one more keystroke to write x+=1. In other words, it avoids potential confusion at the expense of very little gain.
Nathan Davis
2010-09-07 00:25:03
Really? Honestly? What about `a = b[x++]` versus `a = b[++x]`? Are you honestly telling me you've never confused the two or had to think twice about it?
Nathan Davis
2010-09-09 17:53:10
+2
A:
Of course, we could say "Guido just decided that way", but I think the question is really about the reasons for that decision. I think there are several reasons:
- It mixes together statements and expressions, which is not good practice. See http://norvig.com/python-iaq.html
- It generally encourages people to write less readable code
- Extra complexity in the language implementation, which is unnecessary in Python, as already mentioned
Evgeny
2010-09-07 00:28:13
Glad someone finally mentioned the statement vs expression aspect. In C assignment is an expression and so it the ++ operator. In Python assignment is a statement, so __if__ it had a ++, it would likely need to be an assignment statement, too (and even less useful or needed).
martineau
2010-09-07 17:03:33
A:
I believe it stems from the Python creed that "explicit is better than implicit".
Sepheus
2010-09-07 10:15:14
+1
A:
I always assumed it had to do with this line of the zen of python:
There should be one-- and preferably only one --obvious way to do it.
x++ and x+=1 do the exact same thing, so there is no reason to have both.
GSto
2010-09-07 18:16:21