clean code but is O(n^2) complexity. There is a O(n) solution.

Hooray! I'm part of the most common solution group :D

likewise 😭

Good point...

why most "best practices" is for solution that do two sums in every round?

O(n^2) bad solution. Inefficient and slow.

Thank you for the explanations. I think that I am getting a bit closer to understand all of this.

You are almost correct, however, we need to be careful about how we simplify the equations. The time complexity of making a single slice is (omikron) O(n). Making two of them, theoretically has a time complexity of O(n + n = 2n). Note that we are adding, not multiplying. Since 2 is a constant, we can omit counting it. (In other words, the functions n and 2n grow at the same rate.) Just making the slices has therefore a time complexity of O(n).

This happens for every element, so we then multiply by n and get O(n²).

Trying to understand the complexity here, am I right to think this is quadriatic due to fact that each slice operation time complexity is (omega) O(k). So as we doing two of them it is O(k) * 2 = O(k^2). Then there is iteration cost which is O(n). Not sure if this can be seen as k elements in the list as well therefore with slicing together ending in worst case scenario complexity of O(k^2) * k or O(k^3). Does this make any sense? :-)

Souce of info: https://wiki.python.org/moin/TimeComplexity

It's a possibility and a smart one, but absolutely not "Best practice". In the worst case, the slice has to go over all the elements of the array and since it happens in a loop, the function ends up being quadratic (= time needed for its execution is proportional to len(arr)^2). However, this could be solved with linear complexity (= time needed for the execution is proportional to just len(arr)).

My solution = same as top, I'm overjoyed 😭

I found myself in the same situation XD

O(n^2) !!!!!!!!
can write an algorithm of order n