Test cases a bit weird.

def parts_sums(ls):
  pass

This trivial thing causes memory buffer because of the expected results.

I think there where two issues:
The Server was probably a bit overloaded at them moment, because I tried a few of the approved solutions, even they produced the timeout error for me.
The other thing is, that my code used the native reverse() function in python and it seems like this function is horrificly slow (at leest this is claimed by some sources on stack overflow). I made a few minor changes to my code, to not include the reverse() function and it passed all 65 cases.

First: thanks for your approval!
You can take Crystal and/or C++. I am working translations of some other languages.
I haven't seen you since long... Have a good day!

I've just tested it and it worked for me in 3.6, is your solution O(n)? That's weird, the final tests should be 65.

I feel like something is wrong with the python test cases for this kata. I am using python 3.6
My first attemt satisfied the sample tests, but when attempting the solution I got a timeout.

I am aware, that the final test lists can get very long, so I redesigned my code, to only itterate once over the given lists and only create one other list, to hold the solution. IMO the only way to cut computation time further, is to write the solution into the given list progressively, which is but very messy design IMO. However I still get a timeout for the attempted solution.

But the messiest part about this: When I throw in a few print() statements for debugging, I suddenly finished the final attempt with 22 correct and 0 incorrect solutions within 3400ms. The same code without unnecessary print statements would not be able to finish under the 12000ms limit....

I just checked and the random lists can contain over 50.000 elements, so you should try another approach which requires less computation.

I pass the sample tests or any test that I give myself, but on attempt I'm timing out.
Locally, when I feed my code with lists containing up to 30k numbers it finishes below 12k ms mark.
Is it possible that here the tests on attempt contain unnecessarily huge lists?

I second this.

There should be a clarification in the description that multiples of both 3 and 5 should be included just once in the sum.
For example, 30 = 5 * 6, but also 30 = 3 * 10. The same is for 15, 45, 60, etc. In the current tests those numbers go once in the sum.

Arghhh bummer, for some reason I was reading it as k being the base and 3 the power.
Thank you @Chrono79.

Please, read the instructions again, the base is always 3:

Given a positive integer N, return the largest integer k such that 3^k < N.

k is the number you have to return, and N the passed parameter.

The cube of 1 is 1. So the largest cube of positive integer smaller than 3 is 1 not 0. Therefore largestPower(3) = 0 is incorect. The same goes for N = 2. In case of N = 1, 0 would be the largest cube smaller than 1.

3 < 3 is false. That's why 1 is not right, but with k = 0, 1 < 3 is true.

In the exaplanation of the problem there's an example: largestPower(3) = 0, which I think it's untrue.
It should be largestPower(3) = 1.

This was also in the sample tests Test.assert_equals(largestPower(3), 0) and was making the problem impossible to test. If the same test is run on an attempt I think it would never pass.

Can somone look into this?