# Why compiler doesn't support in(de)crement operation? Should we support it? **URL:** \ **Category:** Ideas\ **Created:** [August 19, 2019, 5:12pm UTC](https://discuss.python.org/t/why-compiler-doesnt-support-in-de-crement-operation-should-we-support-it/2181 "2019-08-19T17:12:40Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![shihai1991](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/shihai1991/32/1153_2.png) [@shihai1991](https://discuss.python.org/u/shihai1991)\ **Post date:** [August 19, 2019, 5:12pm UTC](https://discuss.python.org/t/why-compiler-doesnt-support-in-de-crement-operation-should-we-support-it/2181/1 "2019-08-19T17:12:40Z")
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](https://bugs.python.org/issue37304) 2. [https://stackoverflow.com/questions/1485841/behaviour-of-increment-and-decrement-operators-in-python](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](https://hackernoon.com/modifying-the-python-language-in-7-minutes-b94b0a99ce14) ---
**Author:** ![pf\_moore](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/pf_moore/32/35_2.png) [@pf\_moore](https://discuss.python.org/u/pf_moore)\ **Post date:** [August 19, 2019, 6:23pm UTC](https://discuss.python.org/t/why-compiler-doesnt-support-in-de-crement-operation-should-we-support-it/2181/2 "2019-08-19T18:23:27Z")
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. ---
**Author:** ![aeros](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/aeros/32/4140_2.png) [@aeros](https://discuss.python.org/u/aeros)\ **Post date:** [August 20, 2019, 2:02am UTC](https://discuss.python.org/t/why-compiler-doesnt-support-in-de-crement-operation-should-we-support-it/2181/3 "2019-08-20T02:02:07Z")
Thanks for the idea. > [@pf\_moore](#): > > Basically ++ and – don’t fit well with Python, and aren’t needed. I’m -1. 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. ---
**Author:** ![shihai1991](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/shihai1991/32/1153_2.png) [@shihai1991](https://discuss.python.org/u/shihai1991)\ **Post date:** [August 20, 2019, 6:08am UTC](https://discuss.python.org/t/why-compiler-doesnt-support-in-de-crement-operation-should-we-support-it/2181/4 "2019-08-20T06:08:22Z")
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 🙂 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 > **[Python static code analysis](https://rules.sonarsource.com/python/type/bug/rspec-2319/)** > > Unique rules to find Bugs, Vulnerabilities, Security Hotspots, and Code Smells in your PYTHON code ---
**Author:** ![Marco\_Sulla](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/marco_sulla/32/1451_2.png) [@Marco\_Sulla](https://discuss.python.org/u/Marco_Sulla)\ **Post date:** [December 16, 2019, 3:18am UTC](https://discuss.python.org/t/why-compiler-doesnt-support-in-de-crement-operation-should-we-support-it/2181/5 "2019-12-16T03:18:39Z")
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. ---
**Author:** ![apalala](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/apalala/32/683_2.png) [@apalala](https://discuss.python.org/u/apalala)\ **Post date:** [January 10, 2020, 8:34pm UTC](https://discuss.python.org/t/why-compiler-doesnt-support-in-de-crement-operation-should-we-support-it/2181/6 "2020-01-10T20:34:47Z")
For `++i` one can use. ```auto (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. ---
**Author:** ![shihai1991](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/shihai1991/32/1153_2.png) [@shihai1991](https://discuss.python.org/u/shihai1991)\ **Post date:** [January 31, 2020, 2:45pm UTC](https://discuss.python.org/t/why-compiler-doesnt-support-in-de-crement-operation-should-we-support-it/2181/7 "2020-01-31T14:45:43Z")
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](https://github.com/python/cpython/pull/18297)) . It will break the backward compatibility, so it need core developers’ support.