I admit I'm not a serious programmer, but unfortunately I'm not joking either. This is the first time I'm seeing x be a vertical dimension and y a horizontal one.

There seems to be a complete mismatch in the order of the coordinates between the example and test cases on the one hand (y, x) and the clarification on the other (x, y).

The output directions in the example suggest that toll_map is a list of rows (instead of cols) which means a cell is accessed via toll_map[y][x]. And the value of finish suggests that even tuples are in this y, x order. Looking at others' comments this seems to be the case for test cases as well, e.g.:

(3, 0), (3, 7), ['right', 'right', 'right', 'right', 'right', 'right', 'right']

The simplest fix is to just transpose all direction strings in the example output and test cases which would swap y and x and confirm to the more sensible format in the clarification. I know this would break already submitted solutions but 13 is not that many and given the age of this kata all submitters are most likely still active.

My bad, it really was because of infinite loops. It was the first thing I thought about actually but ironically my logging attempts to detect that were cut off in the output due to timing out itself.
The problem was I was interpreting blank clues as "anything goes" instead of "no cells filled". Should have read the instructions more carefully.

I'm timing-out with Python but when I look at the reported timings in the output (on the "Train" page) their sum is well-below 1200 ms - my last attempt timed-out at 200 ms, while individual tests, including the random ones, take between 10 and 30 ms. I'm also testing the same inputs on my machine and none of them caused any issues so far.

The instructions (on the "Train" page) include this caution at the top:

Caution: The Python version of this kata is known to have some problems, likely due to changes in our system since this kata was created. It may not be completable due to these issues.

Are these problems related to timing?

This was surprisingly simple and short. What required some thought was how to validate and transform block positions, while for the path itself a boilerplate BFS without any heuristic was sufficient. A very neat puzzle nonetheless.

Perhaps a more difficult version could be made with larger and more complex grids where such a naive solution would timeout.

Check closely all the places where you're decoding/encoding strings. It could be that you've already encoded that output string back to utf-8 elsewhere, which would explain why string's bytes are not in ascii range. In other words, you might be trying to encode the same string twice.

All of these superfluous encoding/decoding issues could be get rid of if the tests themselves simply declared these strings as unicode in the first place.

Sample tests run the solver twice for each problem:

test.expect(blox_solver(x) in example_sols[i],blox_solver(x))

I suggest this be changed so that blox_solver(x) is called only once for each problem.

Why is Python 3.x not available for this one? At least the supplied strings should be unicode e.g. prefix them with u in the tests, like this: u'カタカナ'. That will make it a 4-character string instead of 12-character.