But typhints in Python are just crutches for developers wishing some semblance of typesafety in an inherently weakly-typed language. They need some kind of static analysis tool to actually make use of this.

On Codewars, there is no such static analysis. The input and return types should be given in the description, aka the specification of the task. Typehints in the solution just clutter up the code and make it frankly less readable.

When a certain degree of knowledge is required as a prerequisite for the kata, without being specified in the kata, I would mention that in the description. Optionally, add a link to a useful site for beginners to learn about the topic.

If we follow the best practice, a function should always return the same type. This will make it easy to translate the problem to languages such as C++ and Java. I would also encourage authors to use type hints in the Solution Setup code.

from typing import Tuple, List


def help_jack(protons: int, neutrons: int) -> Tuple[int, int, List[int], int]:
    # code here

or if we allow the function to return strings too, then:

from typing import Any


def help_jack(protons: int, neutrons: int) -> Any:
    # code here

Background information is often not necessary to specify the algorithm required to solve a task. It mostly serves as a "motivation" section. However I'd expect at least the following things:

1. The description is self-sufficient to solve the task

2. The background information is correct

3. The task is actually conformal to the background information, or reality

In this case, 1 is sort of lacking, and 3 has gone very, very wrong, which is why I raised an issue. Getting 3 wrong would be misleading at best.

Returning different types (list/string) and different things (element name / element info / error messages) is a very bad idea.
When there isn't a valid result, the function should raise an exception or return a "no-value" object (None/nil/null).

In python the return type should be a tuple, the natural way of returning multple values (lists should be used for sequences).

Huh, if a problem requires external knowledge, do you need to teach it to the user in the description?

I get it that a Hey, you need to know this, this and that about chemestry to solve this, would be nice, but do you really have to spoonfeed the chem knowledge to everyone.

I honestly have no idea here, don't make any decisions based on my comment, I just think that a simple heads up You need to know some basic Atom Chem is enough.

Another example would be like, if I had a kata on integration (the math calculus thing), do I have to teach the user how to integrate or does it suffice to say You gotta know some Calculus 2 to solve it?

Don't bother with me coderman1018, this is more of a question of mine for dfhwze (though if you have an answer, feel free to share).

Fixed. The prerequisite knowledge is mentioned in hints.

The kata also does not mention the prerequisite knowledge a user must have to even understand what this kata is about.

Oh god, these comments remind me why I never make any katas outside of the subject of math

Now only first 20 elements are considered

Only first 20 elements will now be tested to avoid exceptions.

(moreover, we already have a kata specifically about electronic configurations (and doing it right))

IMHO electron configuration should be removed from the kata. Thre are too many exceptions and there isn't a simple rule (except hardcoding). There are also elements without a single undisputed configuration (e.g. nickel).

On top of what @voile pointed out, electrons are not always filled in the closest (least n) shell first. For example, 4s is filled before filling the 3d. That means first 2 electrons will be filled in n = 4 shell before completely filling the n = 3 shell. There is an (n+l) rule or Aufbau Principle which is used to understand this. And note that Aufbau Principle also has a few exceptions.

https://en.wikipedia.org/wiki/Aufbau_principle

https://byjus.com/chemistry/aufbau-principle/