Oh, I got it now. You were right, I was couting rows and columns (row 0, row 1..., column 0, column 1). Thanks so much!

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)

I explained bad myself, I think. Not talking of writting the grid but the position you should step. I mean, in the first example the first position (the starting "@") should be (1,2) (x,y), and the first step in order to go to the key is going up to (0,2), right? So when you say the array that should be returned with the pair x-y steps, you said "[(2, 1), (2, 0)...", there is where I am lost. Sorry for my clumsy english, I am explaining myself as hell...

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.

Hello, sorry for the dumb-newbie question but I don't understand the first example. I mean, I suppose isn't wrong 'cause have been tested and achieved so some of them will pointed to it of ot were the case, but, "x" and "y" seems to be swapped to me. If "x" is for horizontal and "y" is for vertical: won't be "@" (1, 2) and first step to (0, 2), then (0, 1) and so on? Thanks.

Sure! Thanks a lot!

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.

I know it has been more than a year, but just in case someone else has the same question. It depends on the kata creator, and most of the time, if validation is needed, it is specified in the description. However, in this specific case, it is not, and there are cases with negative numbers that need to be considered as 0, and values over 255 that need to be considered as 255. One thing that is specified is that you need 6 characters solution or won't work, this is because by default, zeroes on the left are deleted.
That's why it is useful to use control codes to identify when something is not working.

New thing learned! Achievement unlocked!

I was totally unaware of the existence of that method in Python.

I know, I know... I think I put some unnecessary parentheses extra...

That's the reason of my answer but I am doing my best. Anyway I asked this 4 months ago and now I understand it and noticed is pretty obvious. Thanks for the answer.

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