So you're saying python isn't for people who want to solve algorithms in O(n) time where possible?

ALWAYS

unless

...so?

Thanks. For now information is enough.

What complexity is about: how does the time processing grow against data growth.

Think about how many times you have to parse data. If you parse it once, that's O(n). Twice should be O(2n) then, but we consider it as O(n) cause time processing still grows proportionally with data size. That's what we want to know. If you parse the whole data for each item, the processing time grows quadratically with data, that's O(n²). You can see n as number of items.

So from here, you can deduce we also can have O(1): you don't parse data; O(n³): you parse whole data for each item for each item; O(n!): you parse whole remaining data for each item, O(log(n)): you parse half remaining data on each iteration; etc.

You'll easily find documentations, graphs, tutorials, and so on (even hundreds pages book). Just look for it :)

(If needed, a real pro will complete, precise, or correct…)

I want to know more about code complexity. How do you know if it O(n) or higher? I did this solution as described here, but I did it cause codewars makes me think in that way, you know.

Recursion is ALWAYS a BAD IDEA! unless the boundaries are known before hand.

You also have to remember that this is codewars. If the code needed to be time critical, the tests would reflect that. Speaking of which, if your code needs to be time critical in the real world, Python isn't the language for you, otherwise it's good enough for most jobs ;)

See the discussion here: https://github.com/codewars/codewars.com/issues/1391

"Efficiency" score is definitely lacking: how many of best algorithmic solutions are buried under mountains of shortest but not so good and/or unreadable ones… :( Maybe a "golf" (shortest) score would end the misuse of the "best practices"?

True

O(nlogN) -> You can solve it on O(n)