Fighting for 0.2ms is micro-optimization

Micro optimization? For me, using his set approach doubled the execution time. In no way is changing that a micro optimization. With input row, where len(row)=725, it took 0.15ms with my current dictionary solution, using set approach instead, increased it to 0.32ms. Using your proposed alternative took no less than 0.20ms.

Also, I think that your comment should have a spoiler flag.

@realitant test output has been changed so that it's no longer vague or asking you to comb through large lists for some unspecified problem. The description typo with string/line for a single word has also been fixed.

If only one word fits on a line, it should be left-aligned and no trailing spaces have to be put after it.

The description somewhat assumes that you already have a rough idea how justify alignment works. Maybe I should try to reread it provided no prior knowledge.

Also the high number of issues comes from exceptionally bad assertion messages and the fact that the kata is old and was not fixed (and still is not in many languages) for 10 years.

So what you're saying in a really round-about way is that the word "Strings" should be replaced with "Lines"

If that change gets made, one may as well also fix the rule above it:

Last line should not contain '\n'

which I really think ought to say "should not be terminated by '\n" (or be merged with the other line which already says the same thing, that they're separated, not terminated, but either way, they're not freaking contained, same as how a word does not contain space)

In each line you should put as many words as possible. Only then you begin to fill and align the next line.

Have you ever seen how justify works in your favourite word processor (e.g. MS Word or LibreOffice Writer)? There are no leading spaces.
Lines with only one word fitting on it are covered by the rule

Strings with one word do not need gaps ('somelongword\n')

There's a space there in the input, which you can see by printing the input. Please check the input/output very carefully before creating an issue.

The only issue I'm seeing is that the python version has poor test output. Guess it's gotta earn its 4kyu somehow.

Java conventionally uses camelCase though, and the code examples from the description make it clear what the method name is.

If you look at the test cases, you will see that all the tests consider that there are 101 student, with each grade from 0 to 100 being gotten exactly once. "random" isn't even imported in the code.

(OP was working in Python) I removed the purity check. Letting users mutate the input is probably not teaching beginners good practices though

Well, in my cellphone it's not visible, so, it's possible. Hopefully, it's clearer now.

See the last example. It is right-justified.

Yeah I was happy that I finally made the fixed test working and boom.