Sorry for the late reply. I more or less abandonded this kata. I now couldn't approve the Python translataion anymore because something was outdated, and because of Codewars' overly strict, simplistic and rather annoying approach to translations: If there's even the tiniest problem with a translation, I can't approve it, but I also can't fix the problem, because I can't edit the translation in even the smallest way. That's just so dumb and frustrating... :-(

Anyway, I copied the translation and now published it. Thanks to everyone involved!

Notif.

Great Kata. I always neglected some concepts in python and this kata made me realise how important they can be. I was stuck doing closures and didn't know how to properly evaluate the function when no more arguments were supplied (essentially my function needed an extra empty () ). Well now I learnt something new the hard way so I won't be forgetting it any time soon.

I might be dumb, but I didn't find a single helpful tip here when I stuck on optimization. So I'll leave one that's probably a bit too obvious: 248155780267521, for example, is a pretty big damn number, but the digits aren't that great, right? The reverse approach, it seems, should do the trick.

A great kata!

Without spoiling too much, you can define ranges you want to check using the tests. Start with a small one and then adjust it (lower and upper bound) accordingly.

My method works, but its very slow since i'm checking every number. Is there a hint to what numbers i don't need to check?

Eh, yeah. (That's my reaction after solving this). Well, it is a very good kata in the sense that it made me realise that I need to approach things with a more relaxed stance. All in all, humbling and satisfying.

To be honest I don't know either that's why I suggested "trying" withoput pointing out a potential "mistake/useless operation" (I have tried the same thing and it times out compared to the += approach and the two solutions have 8 secs difference between them). I have tried to time both approaches on my local machine and it seems to be minor. Theoretically, I don't think there is a difference because strings are immutable and both approaches should create a new string (as far as I understand). I am looking through the cpython github and if I find something I will update the thread.

Update: I have tried OP's solution as is and it timed out. I have tried the inplace addition and reversing and it worked. I have also tried appending (without inplacing) but at the end and not the beginning then reversing and it also worked. So that seems to be what makes a difference. I am not sure how strings are implemented in python (probably linked lists or something similar) but once I can find the source code for (which I couldn't find, can't find a "_string" file on the github repo) I will update my reply.

Update 2: Check this stack overflow thread : https://stackoverflow.com/questions/37133547/time-complexity-of-string-concatenation-in-python. In the accepted answer's footnote there is a mention of an optimisation to string concatenation. In short when you define two string strA and strB, cpython will avoid creating a new copy when using strA = strA + strB or strA+=strB but not when using strA = strB + strA (prepending). This is in line with what I found so I think it is correct. I hope This helps. Take it with a grain of salt though.

If anyone has a better answer or explanation, then please correct me and/or append to the thread.

Cool, thanks. I have refactored the solution to handle them now.