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

• 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.

Since Term and Operator are crucial data structure used by the kata they should be defined in Preloaded and imported by user code and test code.

If user code wants to expand them they can subclass them, and if everyone is handling them properly (like using isinstance instead of is, and match expression which does the former) this should not cause any problems.

• remove the suggestion
• in the "edges cases" section, the wording should be more imperative: that's what the user has to do, not what the tests will do, actually
• 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?
• ...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.

Hi,

that's a pretty interesting idea. But shouldn't it be pushed further, using also other kinds of operators? (unary? parenthesis? ofc, that's a completely different task/setup)

If not, the description should mention upfront that all operators are binary ones. Currently, it's implied for most of the description, and confirmed somewhere in the bottom part only.

Cheers

TODO

More tests

random tests

=> unpublishing. Publishing a kata like this without random tests is just begging for troubles. ;)