Yes, but since I'm not in a "classic" cursus I wasn't sure whether I can use that word ^^

The names are obviously irrelevant, because you precised how they should be interpreted. We're just arguing about standardisation and clarity here ^^ (Maybe var_1 and var_2 would actually be a fair pick, that way you make sure everyone will read the description and not just go with what they think the names should mean)

"professional programmer in training"

A "student"? :D

IMO, the variable names are irrelevant as long as (var_1, var_2) represent (row, column).

Well I'm a "professional programmer in training" and I always use y as the vertical axis when I'm dealing with rows, and most graphic libraries I've used do the same. But I've occasionally seen the reverse notation as well.

I personally think the clearer solution is to replace (x, y) by (l, c) in the description. That way absolutely no one can be confused.

Beautiful one!

I'm glad you managed to solve the kata, but I'm not joking either: when talking about matrices x and y are the most commonly used variables for coordinates representation like in plotting in math. Programming is not math, though - the first axis here is not horizontal but vertical, so x generally stands for rows, and y stands for columns.

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.

Are you even serious? A list of rows is the most common practice where (x, y) means row X, colunm Y; it is even stated in the description that (x, y) tuples should be interpreted as toll_map[x][y] positions, not as toll_map[y][x]. If it WAS a list of columns, it'd be explicitly stated like in this kata (as it's an uncommon practice to do so). Don't raise an issue if you don't understand the task/can't read the description properly.

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.

Now this is just bullshit. No one will change the kata so 13 correct solutions will fail and your incorrect one will succeed.

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.

Just ignore this comment at the top of the trainer: it appears sometimes. Currently, all previous soluitons are still valid, so no problem on this side.

About your solution, it's hard to tell. Are you sure your code doesn't end up in an infinite loop in some edge case? (timing is not reliable when you get a... time out... Actually, you shouldn't even get a time value... unless...)

Unless you're actually not timing out, but rather "printing out": are you sure that the error is not "max buffer reached"? In that case, that would mean that your solution prints too much things to the console.

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.

Thanks for the suggestion. It looks like this may have been a result of the kata not updating properly before, but it's update now.

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.