My implementation is similar to most of the posted solution.

'''

if num <= 0: return False

divisor_list = [30, 5, 3, 2] # or [2, 3, 5]

for x in divisor_list:

while num % x == 0:

num /= x

return num == 1

'''

But it seems that there is not much detailed discussion on tuning the divisor list. In fact, by improving divisors and their order, the runtime might be doubled or more. Here is my explanation:

When above code takes long runtime and many loop, the main reason would be because the loop of "/" and "%" operation. Assuming:

num = (2^a) * (3^b) * (5^c) * <1 or k>,

where k cannot be divided by 2, 3, 5.

Therefore, before getting out of the loop, the "/" and "%" operations need to be executed for (a+b+c) times.

if set([x, x+y, x+y+z]) == set([a, b, c]), where, x = min(a, b, c), (x+y+z) = max(a, b, c) and y >0

if using order of [30, 5, 3, 2], the number of loops will be reduced from a+b+c = **3x**+2y+z to **x**+2y+z+1,

the last 1 is for the penalty of 1 "%" operation as the quotient after "/30" can only be devided by up to two numbers of [2, 3, 5]

I reversed [2, 3, 5] to [5, 3, 2] is to scale down the num faster during the loop.

By playing the speedup trick of tuning divisor order, my python submission constantly reduced the runtime by 50%.

I also tested divisor order with [810000, 900, 30, 15, 10, 6, 5, 3, 2], and [30, 15, 10, 6, 5, 3, 2]. I didn't see much difference on runtime.