fixed, and also massively improved the random tests (they were expecting 0 most of the time) and added assertion mesages

fixed

I used string.printable instead of just ascii letters. Just using ascii letters for the random tests now ✅

Oh yeah and the 5th case is totally a problem on my solution. Will try to fix it

The last vowel not needing to be broken apart is the reason why the "The final result should have exactly one vowel per line." sentence is in the description. Since if there would be a line break after the last vowel, there would be no vowel in every line anymore

though unclear which

That's the reason why I included Merriam Webster's definition of when y count as a vowel:

The word has no other vowel

which I interpreted as "the word not having a, e, i, o, or u"

So for szyldyk (which I have replaced to szyldy due to @hobovsky pointing out that szyldyk doesn't actually exists), both ys count as vowels

My solution might have counted other characters as letters. So I replaced string.printable in the random tests with just ascii letters

I understand, I forked it and tried to fix most of the problems without modifying the original too much, I think in the end it didn't work out very well

I implemented your test cases, it seems reasonable, but it is generating a much larger amount of numbers that should be doubled, than tricky doubles, anyway

I understand that your code generates numbers with greater variability trying to cover all cases, I just don't have enough knowledge to understand it in more depth, but we can still do the tests using the numbers generated in your code, do you think we should do this?

Hello, you are right, I was thinking incorrectly, the problem was that the tests were letting this type of solution pass, I added another fixed test case, and now it is also generating random test cases that cover this type of situation.

I'm testing your solution in my IDE and it gives a different result than the solution on the platform, I can't understand it

• I added a validation to check if the number is not already a duplicate.

• I set the number of random tests to be fixed, it doesn't make sense for the number to really vary

I misread what you meant by "2 spaces". I thought you meant before the brackets :P

I have 0 experience in Python (my high school teaches Python, but since I'm competing for their computer science team I study strictly Java of which is the language used in the competition) so I'm just going to trust your translation and probably have my classmates and teacher run tests on it. I'll let you know if we find anything.

I looked at the diff and I think it looks good.

Thank you for the translation!

I appreciate your feedback.

I include and mention private L and private R to let the solver know that they exist, but that to actually do anything with them they would have to use the public methods provided. It also helps them to understand that the next roads are indeed Road objects and that a Road could be thought of as a sort of Node. I feel that if I had not mentioned them, the kata would be needlessly more confusing, especially to 7kyu programmers (the target demographic of this kata). If I am to make a kata about using limited resources, I must of course give the solver adequate information about those resources.

Though, I am not sure what you mean when you say that they are "not conceptually the same type."

About the getters, ... I simply forgot how inheritance worked. I thought I would need them to access information about a Road when calling from other Roads, but that does not seem to be the case. Thank you for enlightening me.

About that space issue, I will of course fix it.

Ok, now it should print a nice error message for your solution.

Done (I think...?).

Thanks! I do not know if the rest of my code is Haskell enough, so feel free to vandalise to any extent you consider necessary. I will approve next time I come around.