Prefix and postfix increment

Python Help
1

when will prefix and postfix increment be added?
it is not logical to do it this way i += 1. i += 1 should be done only in recursive algorithms such as qsort, mergesort, dfs. this i += 1 should not be in cycles:

i = 1
j = 1
while i < 10:
    while j < 10:
        print(i * j, end="\t")
        j += 1
    print("\n")
    j = 1
    i += 1
this is how it should be
i = 1
j = 1
while i < 10:
    while j < 10:
        print(i * j++, end="\t")
    print("\n")
    j = 1
    i++
2
1 Like
3
  1. Simple increments and decrements are not needed as often as in other languages. You don’t write things like for(int i = 0; i < 10; ++i) very often in Python; instead, you do something like for i in the range (0, 10).

What I use depends on what I want to use, all languages ​​need increments because the language can’t exist without loops.

  1. This isn’t a decision about whether it makes sense or can be done - it is, and it can be done. The question is whether it’s worth adding a benefit to the core syntax of the language. Remember, these are four operators - postinc, postdec, preinc, predec, and each of them should have their own class overloads; they should all be specified and tested; this would add opcodes to the language (implying a larger and therefore slower VM engine); every class that supports logical increment will have to implement them (on top of += and -=).

python is already a slow language, what happens if it works a little slower? nobody chooses python because it is a fast language. Everyone has accepted that it is slow.

and this answer was given 14 years ago, I think that in 14 years processors have become fast enough to support 4 additional classes that will service prefix and postfix increment.

4

It is exactly about these 2.

A. Can it be done?
B. Theoretically, anything can be done.

A. Does it make sense?
B. Depends what you mean by that. Does the concept makes sense? Yes. Does it make sense to implement it in Python? No.

A. Why not?
B. Because it is a very large breaking change. And given current situation, the benefit that this offers (which I am sure a lot of people have different opinions about) in no way justifies breaking change of such scale. There have been much more valuable ideas with much smaller backwards compatibility issues that were rejected.

A. If there were no backwards compatibility issues with this, would you support it?
B. Yes, these are very fun! But I have just made peace that it is not going to happen until at least Python 7.

1 Like
5

Python has already broken backward compatibility in its history, and I’m 100% sure that it will happen again and not just once. Then what’s the point of waiting? Maybe it’s time to break compatibility once but add a lot of useful stuff? If not, then there’s no point in me even asking about adding logical operators &&, ||, !. and about the ternary operator too ? : . And I wanted to ask what kind of horror is this value_if_true if condition else value_if_false ? and this too [value_if_true if n % 2 == 0 else value_if_false for n in arr]. Doesn’t this code violate the principle of executing code from top to bottom from left to right?

6

Although I agree that it would be good to see some strategic considerations regarding possibility of big breaks, but from my experience current reality is a bit different.

This is the definition of major version increment.
And currently, there are no considerations for Python 4. It is simply too early, no one even wants to talk about it.

On the bright side, from my own experience I have found that 90% of the time the ideas that I come up with:

  1. are already addressed (can be achieved in ways I am not aware about)
  2. can be replaced by constructs implemented in pure python
  3. don’t make sense when I gather a bit more insight about how Python works and situation in general
  4. transform into something else as I spend a more time on them.

For example:
These already exist: &&, ||, ! and are called and or not.
However, they can not be overloaded.
Addition of overloading __dunders__ could be done, however they would not be equivalent due to inability to short-circuit.
numpy community has a certain interest in this and I personally think it is a good idea.
See: PEP 335 – Overloadable Boolean Operators | peps.python.org

Ternary operator already exists and is called a if b else c. Unlikely to ever happen (maybe in Python 4 :)). However, you can just use utility function for it if the order of arguments is what bothers you:

def iff(cond, a, b):

Of course you don’t get short-circuiting behaviour. However if this idea ever develops, lazy arguments could be used for that.

Personally, I don’t like the construct either. I would much rather have C-like ternary, however, Python community is quite strongly bent on readability and this is what they have decided to use.

All in all, I would suggest to start by asking questions in “Help” section regarding things that interest/bother you and only post in “Ideas” after you have spent some time researching, experimenting and thinking about it and it still seems valid to you.

2 Likes
7

I don’t understand why you are OK with += in recursive code but not in loops.

As others have mentioned, Python provides iterators that often avoid the need for incrementing at all:

for i in range(1, 10):
    for j in range(1, 10):
        print(i * j, end="\t")
    print("\n")

This is shorter, clearer, and less error-prone.

Many people have suggested increment and decrement operators. It’s unlikely to be adopted.

1 Like
8

ok, thanks for the clarification. It will take too long for python programmers to want to look at other languages ​​and drag their syntax to themselves. I think it’s easier for me to implement python with normal syntax myself.

9

I meant i + 1. I forgot to remove the = symbol.

10

I think Python programmers have already done that and these are the decisions that were made.

Although very many unique decisions are IMO nicely within the range of “elegance”, some were a slight overextension. I am not fussed about increments too much, but ternary… I tried using it in the beginning, but now I just mostly use full if statement.

However, this is only my opinion and I might be wrong. I am sure a lot of people have different opinions.

And given average Python user these decisions might actually make sense - I don’t have full picture here.

11

Hi Rusian. In C probably, but that j++ is not Python, and Python does not try to have C’s pre and post increment operators. Pythons += is an assignment, and it is purposely a statement not an expression returning a value, which C has.

1 Like
12

The community has a lot of programmers that are experts in more the one language. They are knowledgeable about features of other languages and use that knowledge to inform discussions on adding features to python.

Given that python is implemented in C the core devs all know about C’s strength and weaknesses for example.

1 Like
13

I remember missing them all those years ago when I started with Python. I’m not missing them now. Rarely seem useful in Python, unless you use Python as if it were C.

No. That’s absolutely not how it should be. This is how it should be (already shown by Ned, but I want to show them together):

for i in range(1, 10):
    for j in range(1, 10):
        print(i * j, end="\t")
    print("\n")
2 Likes
14

I also remember reading, and having to decode others pre & post increment of pointers in C code not written to be read. Ugh!