I don't think this should be tagged as "fundamentals". Math and problem solving may be "fundamental" in some sense to programming, but fundamentals katas are about training with a language against the simplest possible problem that exercises the language skills. This means that they are primarily about practicing syntax, not problem solving or math.

A numerical edge case is understandable, but this is a text formatting edge case. The lack of spaces in the string the test means you have to write a specific return case JUST to satisfy that requirement. It's not difficult or interesting, just "if count is this value, return this specific string." If the test were rewritten to say "0 = 0" instead of "0=0" it'd be better and correctly represent programatically dealing with the edge case where the count argument is zero.

If the intent really is to have a text formatting edge case... well, you can do that. It feels tacked-on and doesn't seem to match up with the spirit of the problem, especially considering how easy it is to solve. It's more of a "gotcha", as it's written now.

The requirements for cases of count<0 are trivial and don't add anything to the kata. Suggest making this a "positive only" kata.

As others have mentioned the "0=0" solution with no spaces is inconsistent with the other solutions.

Learned from top solution:

split() already exists. By default it splits a string into 'words' which are any series of strings separated by some form of whitespace.

#Fighting the last war!

• Reminded from solutions that list comprehensions exist. Read up on list comprehensions. Here is an extremely good explanation of using list comprehensions: http://treyhunner.com/2015/12/python-list-comprehensions-now-in-color/
• Learned from solutions that string.center() function returns a string surrounded by whitespace or any other character.

• Learned that .reverse() returns NoneType. If I want to reverse something, I just call reverse() and can't/don't need to set it equal to a new variable.
• Learned from solutions that int() can be used to convert between bases.
• Learned from solutions that map() can be used to apply a function to elements of an iterable.

Actually I'm not sure how the third solution works at all. It looks like it produces a 100% win rate in the case of 'rock' so it should fail every time. I tried forking the solution and running it but there seem to be issues with doing that - even when I fork my own working solutions I get errors trying to run them.

I see that your commentary is the more general (and more correct) version of the things I was observing in these cases. I'll come back to this for reference.

The Python "trueval if condition else falseval" seemed intuitively understandable when I first looked at it. But the longer I think about it, the quirkier it seems.

I guess I knew that you had to return "something that evaluates to a value", ie. an expression. I would have expected conditionals to not be an expression, but it looks like a sort of exception was made for it?

Learned some interesting things from the best solutions:

From https://www.codewars.com/kata/reviews/57e155dded4102075c000087/groups/57e19efe621bcafa9e0014c6

• Learned that I can import things "as name". Interesting for blandly named imported functions.
• Observed that I can refer to an element of a dictionary as if I were referring to an element of a list, using a variable for a key inside the brackets.

From https://www.codewars.com/kata/reviews/57e155dded4102075c000087/groups/57e2545ca396b333e20001c8

• Observed that I could have defined the dictionary outside the function and the function still would have understood it.
• Observed that I can refer to an element of a list inside a dictionary by calling dictionary[variable_equal_to_dict_key][index]

From https://www.codewars.com/kata/reviews/57e155dded4102075c000087/groups/57e247e1ec7d24785a0002df

• Observed that I could include much more on one line if needed. Return may also come before if, else, and other logical statements.

Thanks! I'm checking the solutions that others have done for each problem, once I write my own code. The top solution for this problem includes both your suggestions. The ".join()" aspect of the solution also came up in the best solution to the previous problem I worked on.

I tried to use both "for char in s" and ".join()" when writing this solution, but I couldn't make them work with the knowledge in my head. If I can't write the function with the knowledge in my head, I'll write what I can for a solution. Then, I'll carefully review the best solution and work on similar problems, repeating until I can write the code from my head. This way I learn about features of the language, then I practice memorizing the syntax every time I write a solution.

Eventually the solutions that I write will improve. I find that refactoring the code after seeing a better solution does very little to make the knowledge of how to write the improved code stick in my head, as it never really enters working memory. I'm not sure if I should avoid refactoring completely, though. Maybe I should refactor, but only after some amount of time has passed.