Finding the algorithm isn't enough to be deemed a puzzle, you'd also need to find out part of the specification, which is the case in this kata. Eventhough you give visual examples, the user still needs to find out the pattern. So I would add the puzzle tag.

I didn't solve this version, so I cannot. ;)

Hmmm since it's said that toll_map is a matrix, and there are examples in sample tests, I did not find it difficult to interpret it. But maybe it's just me.

actually, it seems that if you time out, that just means you don't have the correct approach.

alfe, I'm a bit confused by what you're trying to say.

As I said elsewhere in this thread, there's a reason the offcial library solution (the mkdirs() in the os module) is implemented recursively.

Sometimes that's not the case. I haven't heard of a Javascript engine that implements tail-end recursion optimizations. I have also seen incredibly pointless code in widely-distributed libraries.

@alfe I agree that understanding recursion is important and there may be times when it is the best solution. However, it is more important to know when to use it or when not to use it. In this kata what would be the advantage recursion? In this example the recursive solution I was able to find was far more complex then the simplest iterative solutions which didn't rely on any fancy library functions.

I prefer katas with beautiful solutions, and this wasn't beautiful in my opinion.

Them sounds like Haskell programmer words.

This was a port from a Javascript exercise. Actually, I ported the Python myself from the Hy source code, the lisp that compiles to python AST, because I thought it was cute. I modified it so that it fit Surtich's original exercise spec, since I didn't want to change his wording.

Javscript isn't beautiful. Software engineering isn't beautiful (not that this exercise is good engineering). Computers weren't invented by mathematicians. Babbage never finished his. They were invented to do the US Census, to crack Enigma code using a series of hacks, and to account for air resistance for World War II gunners. Actually, we might not have bothered with the air resistance calculations except that all of the hair dressers we had employed doing the arithmetic with adding machines were making too many errors (if you think Python can be ugly, I encourage you to program hairdressers for an exercise).

Historically, sometimes computer engineering was beautiful, but most of the time it was mountains of hacks on hacks. You should check out Goldstein's The Computer from Pascal to Von Neumann if haven't already. The truth about engineering is that things haven't changed much.

If you want a beautiful exercise, check out the Finally Tagless Interpreter kata. This, IMO, the most elegant exercise we have on Codewars.

I intended this kata to be 7 kyu, a fine rating for a simple problem. Additiionally, function composition may be simple, but it is fundemental to functional programming. There being no other function composition kata, I made this one.

Yes, the order does matter, since the tests cases are testing equality of lists of lists. If you sort each solution list it should pass the provided test cases.

I only solved it by introducing a special list class which upon comparison ignores the order of its elements.

This is effectively using set-wise comparison. I can alter the test cases to use set-wise comparison, but the description clearly states that you should be returning a list of lists (not a list of set objects). If you sort each of your solution sets, e.g., [sorted(s) for s in solutions], the tests should pass.

It might be preferable to create a test suite that does set-wise comparison, but since Python's built-in list and set types are not hashable, I'm actually not sure how to easily write such tests.

Edit: I made an update to the description specifying exactly how the solutions should be ordered.

In alfe's defense, the description states: "Write a synchronous function that makes a directory and recursively makes all of its parent directories as necessary".

Does the word "recursively" mean something different here than a direction on how to solve the problem? Maybe something related to unix file system commands?

As I've said elsewhere, you shouldn't be using recursion. It's not best practices. It makes your code slower. Sure, it's cute, but so is a giant my little pony.

You wouldn't want to see your family crushed under a giant my little pony, would you? No, you would not.

And neither should you want them crushed under a callstack by some runaway directory making program.