sum() accepts any iterable so it's not necessary (and actually slower) to materialise the list before passing it to sum. You can leave out the square brackets in which case this will work like a generator expression and pass individual values to sum as sum requests them.

Looks like the timings were not gathered with a tool like Timeit. For small snippets of code, which are affected most by even smallest stuff your CPU can be doing in the background, you should use modules like timeit (or the %timeit in ipython) which will run your snippet multiple times, millions of loops each, to average the result. Timeit can also set up the environment for you (like imports) and not count time for it. For me, in a timeit test of 7 runs, 10 million loops each the results are 30.3ns/27ns/26.3ns confirming the common sense that the sign flip on the int - being a single-bit operation - is the fastest (obviously there is Python layer on top of this but it applies to all three approaches). Hopefully I'm not coming through as a smartass, I "discovered" timeit just recently myself!

Not really, with enough number of executions the differences in individual runs should diminish and you will see true performance difference between the solutions. That's why for small snippets of code, which are affected most by even smallest stuff your CPU can be doing in the background, you should use modules like timeit which will run your snippet 10-100 thousand times to average the result. Timeit can also set up the environment for you (like imports) and not count time for it.

Hi, I wonder if this would pass the current test set where there's "0" at the index position 0 (which you skip), which should appear in the resultset.

The most performant of the top approaches here, Best Practices from me!

Clever use of max() there! That said, in this arrangement the interpreter will evaluate all the operations so not the most performant of options.

Hi, I don't think it needs to - range of inputs is provided in the instructions.

Very close but the result of the comparison is bool already, not need for the IF

This is definitely clever, dynamically resolving an index to list items using boolean to int projection.

That said, interpreter builds the entire list of strings first, then evaluates all the boolean expressions. Based on my %%timeit tests, this is twice the expense of a pure if/else/return approach assuming random distribution of age.

Hi, no - there is similar ** for dictionaries. See https://realpython.com/python-kwargs-and-args/