Is an n + m solution not fast enough? Using Counter with Python runs out of time.

I suggest including additional hints for the python version (like how to generate a signed integer from a string fro example). It's really unsuited to this sort of problem (at least as far as I can tell).

In which case maybe just add Python3 as a separate language.

This is inconsistent with the rest of the series and the instructions don't make any sense.

I think the padding test is broken (or needs to be clarified) for Python:

Testing for 'F' to 'Rg'

'Rg==' should equal 'Rg'

I think this Kata should describe the problem instead of handing it off to a Wiki article which could be a moving target.

I find the explanation of padding (in the article) very confusing, and so do wikipedia editors as it is currently flagged for clarification. Anyway, I think the lack of material in the actual Kata makes this more difficult than it neeeds to be.

ETA: The testing set includes encoded strings with padding, but there are no padding characters ('='). (Python)

This is a fun kata, but I think it should be 3 kyu.

Is there any way to tell which of your solutions has been upvoted? I noticed I got some points for this but have no idea which of my (usually terrible) solutions was somehow marked as clever or best practices.

This problem is frustrating and annoying because if the gotcha about a computer playing itself.

Parsing every single line of the description should not be necessary to start working away at a problem.

At least include the computer playing against itself in the example behavior.

This is a nice Kata but no way should it be a 3 kyu. In python at least I think 5 would be more appropriate.

Read this thread and this problem is still incomprehensible sorry.

I think the very small number of test cases (and the fact the testing stops with a failed test) makes this far more difficult/frustrating than the problem should be.

The "Line starts or ends with a space" error message should include the line number.