I fixed the description to reflect this requirement.

Fixed

And you're not sorting either, you're grouping.

Author is just not using canonical terms for what is happening here.

Arrays and linked lists are functionally interchangable. Top and bottom of stacks are functionally interchangable. The current encoding lets solvers read from left to right the sizes they see from top to bottom.

I'd be worried if I couldn't look through these abstractions. This is CW, not Google; if we were Google, implementation details would matter, on CW, high level designing a solution is much more important.

Fixed :)

Hi, thank you for the advice
"Your variable should return a boolean output" is an obsolete part of the description and will be removed with the next update

I'm currently working on improving my test cases, so this issue will also be fixed with my next update

Author of the BF translation here.

Can you elaborate on the problem you faced with the above implementation?

Based on the task, your BF program should convert a string (e.g. "Hello World!") into a runnable BF code (e.g. "-[------->+<]>-.-[->+++++<]>++.+++++++..+++.[--->+<]>-----.---[->+++<]>.-[--->+<]>---.+++.------.--------.-[--->+<]>."), the tester would then verify that the above newly generated BF code, when ran, produces back the initial input string. (in this case "Hello World!").

Already noted here: https://www.codewars.com/kata/525a3d6b85a9a47fcf00055a/discuss#592edf1df8eaced25c000008

Alright, swapped to pass preloaded.Crate objects and then compare with a test-suite defined version. The example provided now works as expected.

the test code could likewise read out the data and compare that instead of insisting on its own separate definition. could also get fancy and render the states like the drawings in the instuctions. or, only show the preloaded one to the user and then compare with a separately defined type for the expected value. codewars_test does do actual == expected though which is arguably wrong and it should instead do expected == actual

Unfortunately, Crate needs to be redefined in the testing code to be inaccessable to the solver, so you only have access to the definition from preloaded. namedtuples can still be compared with __eq__ from two definitions, but I'm not sure if there's a way to compare them with is or with match statements.

It's an unfortunate effect from a poor choice made early on to use namedtuples, but I'm not sure what difference it makes when solving. There are no invalid inputs and you can still match on crate.color perfectly fine.