Why compiler doesn't support in(de)crement operation? Should we support it?

Ideas
1

I am curious why python doesn’t support pre-increment/decrement operator. Do we have any formal conclusion/

much discuss in:

  1. https://bugs.python.org/issue37304
  2. https://stackoverflow.com/questions/1485841/behaviour-of-increment-and-decrement-operators-in-python
  3. https://hackernoon.com/modifying-the-python-language-in-7-minutes-b94b0a99ce14
2

IMO, the links you post pretty much cover it. Python is not C, and has managed for a long time without ++ and – operators. Also, Python distinguishes between operators and statements. Augmented assignment (+=) is a statement, would you have ++ be a statement (which makes it mostly useless) or an operator (with unexpected assignment semantics)?

Basically ++ and – don’t fit well with Python, and aren’t needed. I’m -1.

2 Likes
3

Thanks for the idea.

Agreed. It’s really just an implicit syntactic shortcut (which Python has a tendency to avoid). I find it difficult to imagine a scenario where you couldn’t just use +=, enum() or next() instead.

Although I’m not opposed to the idea of ++i raising a SyntaxError, as mentioned on the bpo issue.

1 Like
4

Thanks, guys. I have this question because i found c、java and js support this satetement.

Although I’m not opposed to the idea of ++i raising a SyntaxError , as mentioned on the bpo issue.

kyle abserved this detail :slight_smile: If the python object is immutable object, we don’t support such complex statement, should we raise the syntaxError when user use ++i too.

ps: i found some scan tool have this check rule, such as: sonarqube

5

Well, can I say that i++ and i-- are quite handy? I means, it seems stupid, you have to write only one more character (or 3, if you want to make it more readable). But I can’t explain why, I feel it much more simple, and when I program in Java the only thing that really make me happier is i++ and the implicit conversion between strings and other object with +

I think ++ and -- should be considered operators. And the good think it’s they could also used for other purposes… for example, you can write iterator++ instead of next(iterator)!

About ++i etc, I’m against it. I think they only complicate the reading of code.

1 Like
6

For ++i one can use.

(i := i + 1)

In languages like C, i++ yields the current value of i, and then increments. To match the semantics of next(it) it should be ++it.

I agree Python doesn’t need operators with semantics that default to modifying their arguments.

1 Like
7

Thank you for everybody’s comment.

According to comments, most people doesn’t support in(de)crement operation.
I write a PR which could raise a syntax error if user use in(de)crement operation(https://github.com/python/cpython/pull/18297) .

It will break the backward compatibility, so it need core developers’ support.