I can't see your code until it passes the tests, but you can post it here with this format:

```C

// Your code

```

and please check the box "Mark as having spoiler content".

this is a reference to the instance of Number on which you called the method times.

Actually [+] is faster for values in range [129, 255] and [-] is faster for values in range [1, 127].
0 and 128 are indifferent. So you can prefer one over the other only if you have an idea of your values' distribution. In real cases, [-] seems better in most cases, as all ASCII characters are in range [0, 127].

I love this kata, made an overcomplicated boilerplate code, then realised it had performance issues and set it aside for years.
Took it back to realise that the issue wasn't the overall performance, but some long invalid variable names in random tests that highlighted a catastrophic backtracking in my regex ^^

If I understand your approach, in a maze like this you may try every single path inside the top-right square before going back? Maybe even backtracking paths.

# ######
# #    #
# #    #
# #    #
# #    #
# ####^#
#      #
########

An improvement I could propose that comes from A-star algorithm without rewriting all yu've done entirel would be to attribute a "shortest distance to the start" score to nodes instead of some kind of recursive "who visited who" (I'm not sure I quite understand the visited part of your code though), then you only visit a node if its shortest registered distance to the start is bigger than its distance to the start in your path.

Of course that'd just be a patch, I think BFS approaches, from floodfill to A-star to Djikstra are always better than depth first when correctly implemented.

"the only thing that would actually meet that criteria is nested arrays." => Well, no. For instance, an array of string does the job just right.
One could also choose to represent a whole 2D matrix with just one string (i.e https://www.codewars.com/kata/586214e1ef065414220000a8 and other string input katas do exactly that). I'm not sure what makes you think something would be wrong.

The sample tests only show that the expected solution is a tuple, not that you must output a tuple yourself. I don't like using the "philosophy of python" sectarism in an argument, but duck-typing is expected unless stated otherwise.
I've been lazy though, as the output format is actually specified in the 5x5 Nonogram version. So I guess my complaint was invalid.

(Still, I think it's better to clearly state such limitation)

In Python version, the assertion will fail if the result grid is not a 2D-tuple. It shouldn't matter what kind of Iterable contains the answer so long as the values are right.

Should be fixed

Indeed, nothing critical but it's important to get only solution-induced warnings and errors. Thanks for the feedback.

I removed all those salts from the preloaded classes because the scoping was actually doing its job correctly. I'm very sorry for that artifact of my miscomprehension and all induced time loss.

Zsqdfaezr
That means, since I initially thought I managed to shadow your classes despite the namespace for some reason, I added a salt to all my preloaded classes. And I updated the Validators and Test Cases... Of course that didn't update in your editor, because you had saved changes.
The line path_tester = Preloaded.PathTester() at the bottom of the test cases had been changed to [REVERTED] but I wonder if I should revert that salt because it was not the problem or let it, just in case such problem arises later (and is that more likely than other people with backward compatibility issues?)...

Nah, when you do something wrong it's the author's job to tell you what's wrong. AttributeError: 'Player' object has no attribute 'line'" is a bad way to say The input maze was modified. Make a deep copy if you want to edit., I'll update the kata later. Thanks for the feedback!

I was thinking that it made no sense at all, but it was the test cases and not the actual test suite, right? I think it's simply that you modify the input maze as you solve it. Which is a bad practice in general, and in this case confuses the validator that doesn't find a player character to play your solution with.

Please mark as resolve if that is indeed the issue.