My bad, fixed. Small mistake in the solution has occured.

✅ Replaced string.printable with just ascii letters

My solution might count other characters as letter, which is probably why cases like were handled that way

The description is actually internally inconsistent. A newline is to be inserted after every vowel, but the final result should have exactly one vowel per line - presumably including the last line. I've already had breakfast; I'm not believing more impossible things today. This is an Issue.

retired

kata was retired

Updated !

same here

Oops, there was an off-by-one error that is fixed now. So the 3 is cut now correctly.
Thanks for raising this issue!

I have the exact same question. My code passes all other tests execpt this one.

In this case, the "random_valid_key" function will need to calculate 43 numeric digits plus 1 check digit. Try using another function within the code to create the check digit and import it into the "calculate_check_digit" function. As I mentioned, I tested the code on Kate and it works without any errors. As for the "random_invalid_key" function, you need to create a key that does not have the check digit in which case it will always return false, if a valid key is generated it will not pass Kata.

Would you please refrain from posting AI-generated answers all over the place, including Github and kata discourses? They are borderline off-topic, and none of them answered any question in a useful way. Just write your own answer, keep it on topic, and eventually use AI tools for proofreading and spellchecking.

And the problem with random_valid_key and random_invalid_key is in your code and if you cannot see it, no AI will help you understand it.

I tested Kata, and it doesn't show any errors

Time: 517ms Passed: 4Failed: 0
Test Results:
Access Key Validation Tests
Test valid access key
Test invalid access key
Test list of access keys
(2 of 2 Assertions)
Completed in 0.32ms
You have passed all of the tests! :)

Function scope: Make sure the random_valid_key function is in the correct scope to be accessed within tests.

Check that the code indentation is correct. In Python, incorrect indentation can cause problems with function scoping. For example, if the random_valid_key function definition is inside another function or conditional block, it may not be globally accessible.

random_valid_key after tests: The random_valid_key function must be defined before being called in tests. If the function definition code comes after the test block, Python will not find the function at execution time. To fix this, ensure that the random_valid_key definition is above the test call or within the same code block where it is invoked.

Okay, so first, for each vehicle type, compute the inverse weight as 1 / points. Normalize these weights to convert them into probabilities summing to 100%. This is done by dividing each weight by the total sum of all weights. Ensure the probabilities sum exactly to 100% by adjusting the last probability. For each vehicle type, compute the absolute difference between John's probability and the city's frequency and then sum all these differences. Subtract the total difference from 100% to calculate the match percentage: Match Percentage = 100 - Σ|P(Jhon) - P(City)|. If the match percentage is negative, set it to 0.

Here is an example: Points: [1, 3, 5, 6] City Frequencies: [58.82%, 19.61%, 11.76%, 9.81%] | Weight=[1, 1/3 ,1/5 ,1/6] | Sum of weights = 1.7 | Probabilities= [1/1.7, 0.33/1.7, 0.2/1.7, (1/6)/1.7]*100= | Probabilities = [58.82, 19.61, 11.76, 9.81] | In this case the sum is already 100%, so no adjustment is needed. | Differences= |58.82 - 58.82| + |19.61 - 19.61| + |11.76 - 11.76| + |9.81 - 9.81| = 0 | Match Percentage = 100 - 0 = 100.00%

The "match percentage" in this context measures how closely John’s point-based probability distribution aligns with the actual frequency distribution of vehicle types in the city. The purpose is to assess how well John's point system predicts the city's actual vehicle distribution. A high match percentage means the point system effectively captures real-world probabilities, while a low percentage suggests it deviates significantly, potentially making the game less representative of actual trends.

1 word book (only "Persepolis") was badly handled in my code,
it's fixed now :)