Sorted is O(n log n) complexity, both sorted and sort use the same algorithm behind the scenes. Creating a list is O(1).

i did same thing but i just said arr != None its acccepted too here >1

really nice

When we do 'max' and 'min' - there is some kind of sorting happening under the hood for two times.

This is wrong. When we do min and max, there is no sorting happening under the hood, for a total of zero times.

Why is it so? I solved with 'min' and 'max' too, but now I think that 'sort' could be more efficient.
When we do 'max' and 'min' - there is some kind of sorting happening under the hood for two times.
But using 'sort' - sorting happens just once.

According to tests from 'pprunesquallor' - 'sort' is more efficient. As you said - only for short lists.
What lists are long? What is the len value after which 'sort' becomes less efficient?
And why?

But didn't it takes more time for slicing, if there is long list? And what if we check "len(arr) > 2" instead of "len(arr) > 1". Wouldn't it be faster?

An empty list is false(y), so it tests if the list (arr) is empty or not

Why 'arr' is used as condition?

yes, that's the idea: the asymptotical behaviors for big N are:

• O(N log(N)) + N -> O(N log (N))
• O(3N) = O(N) -> O(N) => better

on the top of that, the difference bettween your O(N) solution against the O(3N) is that the O(3N) use only built-in fonctions. That's almost always faster than a better time complexity coefficient (1 instead of 3) with more hand made code.

sure, if you used test cases from the kata with short lists. Try the same with very long lists...

I timed your solution with %timeit and the best run was 1.3 microseconds per loop. The solution above (using sorted) took 1.12 microseconds. My solution which used .sort() took 0.72 microseconds.