grid = [
    0123x
  0'aB..',
  1'##@#',
  2'$Ab#'
  y
]

0, 0 is top left, that's an a
with x-axis being right-left, that means @ is two steps right, so x-axis is 2, and it's one down, so y-axis is 1: (x, y) (2, 1)
I.. don't see how you're getting (1, 2) for @

(1,2) (x,y), and the first step in order to go to the key is going up to (0,2)

if (1,2) is x,y, then you changed the x coordinate but said you're going up, which is vertical(up/down) movement, but you said x is horizontal(left/right)

.. no clue where we're viewing this differently x)

Do you mean that you're writing grid[x][y]? That would be you swapping them, since grid contains rows, not columns.

avoiding the variable names x and y may help. try row and col. and you should always consider re-structuring any input data you receive to suit you.

It works without return because the sample test (scroll a bit to see it in the coding page) tries to call factorial(). Talking about what he imported from math, factorial, it is imported as a function after all. Hope you get it.

There is some recursion there. Please deep your knowledge about it!

Imagine asserts doing what it says on the tin. Yeahh that should (aside from working at all) be on by default. And it also shouldn't catch AssertionError, that's less than helpful. Ideally also change to expected-x-but-got-y wording since y-should-be-x reads like nonsense.

I would rather not become an expert in the Python custom test framework. Nor in Python, actually.

Maybe we can pester Jake to fix things on the 27th. And standardise the test framework to stop its on test failure, like in, oh, all other languages.

allow_raise doesn't do what it's supposed to atm btw, and it never has - this is made pretty obvious if looking at the codewars_test source. there's a pull request to address that that's been sitting unmerged for a while. (essentially it's mixing up two similarly named exception types and is handling the wrong one - this is also why regular plain assertions are treated so weird)

.. surely it can't be that hard to get that merged in instead of doing a bunch of work-arounds all over

Why just for random tests? Solvers can't see fixed test batch size either.

But what good does it do without allow_raise ?

( I would rather have this discussion on Discord. It is not just applicable to this kata. )

I think the number of random tests should always be in the description of each test batch, regardless of allow_raise

And if you spoiler your question, no notification will be sent for it. I stumbled on it by accident just now. Normally, I would have missed it; we're quite far down the page already.

And this, Johan, is why you shouldn't use allow_raise=True. It causes psychic damage to Python only solvers.

The first block has 2 tests, the second 10, the third 100. You are not making it to the end of the blocks.

You are still missing something. See @mauro's comment.

k = 1 does not mean strictly alternating workdays. It means after any work day there must be at least 1 break day.

The blocks stop when you fail a test, so of course you'll always fail the last test in a block. :P The block would not be finished if you passed the test.

This behaviour is by design.

[5, 3, 1, 8],  1    =>   [5, 8]   =>  13