Good point

Python's match() only returns true if the regex matches at the beginning of the string (this is, IMO, insane). The tests should be rewritten to use search() instead.

In the Python vrsion of the kata, your regex has to match the whole string. That must be a bug in the translation?

In the vi mode editor, the Tab key inserts a literal \t character, but using the indent commands (< and >), it changes the indent by 2 spaces. This is a little bit annoying in most languages, but it causes frequent irritating syntax errors when editing python.

I don't think it especially matters which is chosen, as long as the behaviors match.

Having just dipped my toe into trying to learn Clojure using this site, I understand completely. I think a "hint" system is a great idea, but I think there are a few even simpler things that could be done to make the easier katas more approachable to people who are just learning the language. For example, it should be more clear which test is failing, and the kata author could include hints in the test error messages.

I've been thinking about this recently too. It would be nice to keep track of your solution runtimes, and I was thinking that for some katas, it might even be nice to be able to compare solution runtimes with other users. However, the issue is that these solutions probaby run on different hardware at different times, so the results from different runs probably aren't comparable in an apples-to-apples sense. It still might not be an intractible problem, though.

This is a very fun kata. It might be fun to find a way to compare runtimes with other solutions -- this is a case where there are a bunch of solutions and some might be much faster than others.

There are some implementation difficulties I can think of that might make this kind of comparison difficult, though.

I felt like the requirements for supporting chained assignments and parenthese weren't very clearly presented. It's there in the BHF block, but the text doesn't call it out, and it calls out a lot of other stuff, so it seems to me it should also mention those requirements.

Also, I on't know how I feel about defining the problem to take a string as input, but then pre-fills in the tokenization for you. I think it would make more sense to define the input function as taking a list of tokens.

Finally, there seems to be some code in there to support functions in some way, but they're not actually a requirement. That should be cleaned up.

Overall a good kata.