Same issue. You should be able to visualize my code under my initial message.

Is this resolved?
I replaced the thrown exceptions with test.fail and the message except for the table one, but that one's caught an message'd in the table test.

I get this with a code using recursion:

Check for recursion
Unexpected exception raised

Traceback (most recent call last):
  File "/workspace/default/.venv/lib/python3.11/site-packages/codewars_test/test_framework.py", line 112, in wrapper
    func()
  File "/workspace/default/tests.py", line 64, in nonint
    test.assert_equals(ackermann(Nat().s,Nat().s, Nat()), Nat().s.s.s)
  File "/workspace/default/.venv/lib/python3.11/site-packages/codewars_test/test_framework.py", line 35, in assert_equals
    expect(actual == expected, message, allow_raise)
           ^^^^^^^^^^^^^^^^^^
  File "/workspace/default/tests.py", line 32, in __eq__
    else: return self.v == other.v
                           ^^^^^^^
AttributeError: 'NoneType' object has no attribute 'v'

This comes from the tests and not from my code. Tests should be designed to handle this in a cleaner way since that's part of the challenge, so that they don't throw an exception but fail and return a message meaningful to the user.

Rust Translation
https://www.codewars.com/kumite/65054d57bc47bc00316babd1

This kata literally just boils down to copying the top answer in stackoverflow (which shows up as the first search result of ackermann without recursion), so I'd say even a 7kyu a warranted.

Anyways, such kind of kata is not either good or original, so downvoting.

Point one should be good now, the other kata did not show up in my search, that's my bad. (also, really, 6kyu, that seems a bit low, even for a pretty much copy algo from wikipedia kinda problem)

• missing imports and test.it in tests - https://docs.codewars.com/languages/python/codewars-test
• almost duplicate (https://www.codewars.com/kata/5bb3a707945bd500450001cb), but the other kata needs a complete rewrite.

I guess I see what <redacted> is. If that's what I think it is, it makes the kata far less interesting (and almost a duplicate of some other kata, except for the unusual context with the classes). So, maybe adding at least the unary operators would be good? Since those aren't handled by "<redacted>", iirc?

should be good now.

well, even with subclassing, most of the shenanigans will still apply, so I doubt it will change anything. If the classes are in preloaded, the user's function should return the classes they built and the tests should then use them. That would make the setup far more complex (well, actually, no).

Dunno if it's worth of the work, tho

• ok, the point 1 is what I guessed you meant. Better to reword that part, yeah.
• mmmh. I'm not relly versed into the precise categorizations, so myabe I'm actually wrong. Better to check that with some other sources (in my mind, parsing is the whole process from the string to the concrete syntax tree)

I cannot see that comment (since I didn't solve the kata)

If you allow user to arbitrarily modify the class used by the tests, there can be shenanigans to be made. (Considering it's Python...)

since Term and Operator are from the input, subclassing them isn't going to do much sine the test code won't use the subclass. Putting them in preload anyway may be fine, the user can always just remap the input into data structures they find more ergonomic, but I don't really see the advantage.

Two equal operators may or may not compare identical via is. This is totally unclear. I guess you mean that the tests will never try to compare operators?

The point here is that in all the examples, I use something like [Term(1), plus, Term(2), plus, Term(3)], which means the user could figure out that the two operators are the same operator using the python is operator. However, I want to allow the tests to create operators on the fly, so having someones implementation rely on it
would not work.

...and will be parsable unambiguously. There is absolutely no parsing involved, since the inputs are not strings. => that point should be either removed or reworded.

The way I am familiar with the terms is that lexxing/scanning/tokenising would be the step of converting some input string into the kind of list I provide, and parsing would then be converting said list into some sort of (potentially lazily created) tree-like structure for evaluation.

Will reword the edge cases sections and remove the suggestion.