Lychrel calculator (Project Euler 55)
1. Comments on your code


Python has a built-in module, timeit, for measuring the execution time of small code snippets. So there is no need for all that fussing about with datetime.
Project Euler problem 55 says:


  you are given that for every number below ten thousand, it will either (i) become a palindrome in less than fifty iterations


but your code only tries 25 iterations. It happens to be the case that 25 iterations are enough in this case, but how did you figure that out? If you had a mathematical proof that showed that 25 iterations were enough, then that would be fair enough, but I suspect that in fact you re-ran the program with different values for the count of iterations until you found that smallest one that produces the right answer. This seems like cheating to me: if you are willing to do that, why not just replace the whole program with:

print(answer)


which would be even faster?
The problem statement asks:


  How many Lychrel numbers are there below ten-thousand?


but you test range(10001) which is off by one. Luckily for you, 10,000 is not a Lychrel number, so this doesn't lead to an error.
You've made candidates into a global variable, and run some of your code at top level. This makes it hard to test your program from the interactive interpreter. You need something like this:

def problem55(n):
    """Return a list of Lychrel candidates below n."""
    candidates = []
    for number in range(n):
        if is_lychrel(number):
            candidates.append(number)
    return candidates


and then you can test it like this:

&gt;&gt;&gt; from timeit import timeit
&gt;&gt;&gt; timeit(lambda:problem55(10000), number=100)
8.279778157011606



2. Speeding it up


The problem statement only asks how many Lychrel numbers there are, so there is no need to construct a list of them.
Function calls in Python are moderately expensive, so you can save some time by inlining them. This leads to an implementation like this:

def problem55_1(n, m):
    """Return the count of numbers below n that do not lead to a
    palindrome after m iterations of reversal and addition.

    """
    count = 0
    for i in range(n):
        r = int(str(i)[::-1])
        for _ in range(m):
            i += r
            r = int(str(i)[::-1])
            if i == r:
                break
        else:
            count += 1
    return count


which is about 16% faster than yours:

&gt;&gt;&gt; timeit(lambda:problem55_1(10000, 50), number=100)
6.93482669594232

Janne suggested that you could speed things up by caching the numbers already found to be Lychrel and non-Lychrel, and you replied:


  doing that is going to require more conditions and probably is going to be the same running time or even worse


which is a bit of a defeatist attitude. Certainly the code gets more complex when you add caching, but it's not a priori obvious whether this costs more than it saves, or saves more than it costs. The best way to find out is to knuckle down and try it:

def problem55_2(n, m):
    """Return the count of numbers below n that do not lead to a
    palindrome after m iterations of reversal and addition.

    """
    lychrel = set()
    nonlychrel = set()
    count = 0
    for i in range(n):
        j = i
        if i in lychrel:
            count += 1
            continue
        stack = [i]
        r = int(str(i)[::-1])
        for _ in range(m):
            i += r
            if i in lychrel:
                count += 1
                lychrel.update(stack)
                break
            if i in nonlychrel:
                nonlychrel.update(stack)
                break
            stack.append(i)
            r = int(str(i)[::-1])
            if i == r:
                nonlychrel.update(stack)
                break
        else:
            count += 1
            lychrel.update(stack)
    return count


I find that this is about twice as fast as your code:

&gt;&gt;&gt; timeit(lambda:problem55_2(10000, 50), number=100)
3.935654202941805

One final tweak from me. Now that we are caching, the order in which we check numbers for the Lychrel property matters. As you iterate the reverse-and-add process, the numbers get bigger. So if we start with the larger numbers and proceed downwards, then we are more likely to get cache hits. So I tried replacing the line:

    for i in range(n):


with

    for i in range(n - 1, -1, -1):


and got a further small speedup:

&gt;&gt;&gt; timeit(lambda:problem55_3(10000, 50), number=100)
3.800810826011002