Cheers @hobovsky, was just popping back in to explain + apologise for the confusion but I see you've beaten me to it.

As explained to the OP on Discord:

The guideline is (or, appears to be) a bug in docs.

Blatant violations of language idioms, and of practices commonly recognized as correct or good (including kata authoring guidelines) are usually a valid kata issue.

I'm guessing that there was once a stricter intention for issue tags which has now drifted; most of the issue backlog doesn't fit this guideline. I've pinged the mods to clarify what's meant to be happening.

The kata should be rewritten without the useless class

• in python function names should be snake_case.
• submission tests should include sample test cases
• fixed tests should come before random tests

• an issue is always an issue
• don't close issues without solving them

Per the discourse guidelines;

If the kata is in the beta process, then logging issues is OK for things like needing random test cases, or changes that are otherwise not critical to completing the kata but would make it better. However if the kata has been approved then please only log issues that are preventing users from completing the kata.

Closing this issue; you may want to re-raise it as a suggestion instead.

In python function names should be snake_case.

I can't wrap my head around the fact that I can solve this kata by removing the initial code.

Why add those lines if they complicate the Kata unnecessarily?

Would love some insights since I'm a beginner

Author is gone. According to docs: https://docs.codewars.com/concepts/kata/translations/ please label your comment as Suggestion.

Is there a chance that random test cases are wrong? Nah it was on me, sry.

L discription!

I made a Python translation can author of kata please approve

TBH, type coercion in JS is terrible both as a concept and as an implementation. As many other things in JS. But that doesn't mean anyone should "prefer Python instead".

I did the same. After reading description I understood it just like this: there should be one step undo and (therfore) one step redo. Maybe that would be good to address this in the description somehow?

A function-based class is still a Class.

Why not simply ask for a function that, given inputs weight, crew and balloons, outputs a Boolean indicating whether or not it'll fly?

What is the added value of having to create a new Object first, which will have a method indicating same? If some Object has complicated internal state, multiple methods, maybe a getter and/or a setter here and there, a Class organises that into a neat package (and a single namespace). But this task does not warrant the additional complication, the overhead of a Class. It doesn't need namespacing, it'll never be more than a single name, and it has no state really, just inputs. That Piracy kata is another example of this; it could have been done as a simple function, which would have been a oneliner, instead of a class with one method and no real state.

Doing things with class is a noble endeavour, but justify the aditional complexity by using the Class to simplify things instead of complicating them. That means you need more complexity in the task to start with.

My opinion. Which is why this is a suggestion and not an issue.