A belated thanks for the review and the feedback!

6) on my list is such a case:

input:    'a5 '
expected: 'a-\n5 '
but got:  'a5 '

and it also doesn't hold when there are \n's in the input

furthermore the description contradicts that by saying that there should be a \n after each vowel

if you say that there should be exactly one vowel on each line, then one needs to be able to split it into lines and find a vowel in each line. that is not the case.

The reason that the sentence exists is because I want "Ho-\nme-\s" for "Homes" to be wrong and "Ho-\nmes" not
Also the reason why this is not the case is because my solution might have counter other characters as letters. So string.ascii_letters is used instead of string.printable for the random tests

Schönen Tag noch!

Thanks!

good that it didn't let you down after all

Also, I don't think I've seen a level 5 that doesn't require a loop.

It can be VERY hard to solve certain problems without a loop. In fact, some performance kata's require a O(1) solution, instead of O(n), so don't judge a kata's difficulty on its flavour for loops.

By the way, what exactly is needed to approve? I sometimes see the green bar "You have the ability to approve this kata. You simply need to edit the kata and set its rank. .... Edit/Approve Kata"

I see the average rank. But if I republish, it doesn't seem to have any effect. Do I have to edit the description in some way?

Thanks for approving.

Maybe I should explain why I originally posted the kata at rank 6.

The book only shows that one example, which is a simple calculation. So I was originally thinking rank 7. When I started extending it to other cases, I realized it was significantly harder. (I was only confident my solution was correct when it matched the results of simulation). But I'm not very good at geometry problems, so I wasn't sure how hard it was. Also, I don't think I've seen a level 5 that doesn't require a loop.

No insult to the problem was intended. :-)

Remember that you can always check votes using API link.

You approved at correct level. 6 would have been an insult to this problem.

I've fixed the ordered nature of coordinate pairs I believe. It should now be truly unordered (meaning it shouldn't care if you return, [[0, 0], [1, 1]] or [[1, 1,], [0, 0]]).

The function should return a set of tuples.

What I'm suggesting is that you should decide how the tests should behave and then implement whatever has that behaviour. You would for example need to consider what the failure message should look like, it's not great to show a list that is sorted differently from what the solver returned, so how would a human grading that reply answer? Make it say *that*.

I don't see why you'd intentionally use a less appropriate data type.

I completely blanked that Map is a built-in, oops. I'm not using tuples because IMO it feels a lot cleaner to use tuples, this is somewhat to emulate a more interview-y style set of annoyances. I could reconstruct with tuples though. I can also remove those typing imports then. With regards to comparing the order, the function is going to produce a list of pairs and I'll need to compare that against some reference list of pairs, are you suggesting that I can just sort the internal pairs as well? Something like

sorted([sorted(pair) for pair in pairs])

Just don't compare the order if you don't care about the order? Also use tuple for pairs ([((0, 2), (2, 2))])

you don't need the typing imports, list/tuple support those "operations" directly. list[list[list]] is also really strange as it doesn't specify the innermost element's type, and with tuple you additionally specify how many there are - it'll get quite lengthy though.

someone is going to complain sooner or later that you're shadowing the name map in the default code