It's bad practice to remove them. It's relying on the tests to include them instead, which leaves these solutions prone to being automatically invalidated in the future if the tests change and their solutions don't compile anymore. The line or two saved by omitting them isn't worth that risk, so you're doing good by keeping them in

why theres no #include
i tried it without the lib but dosnt work for me

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

Very readable and logical. Oh, this language design...

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

likewise 😭

where did 'const' go?

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