... oh, that would do it. I didn't know that hex was a built-in, so I had this defined globally:

hex = "0123456789ABCDEF"

Thanks for the help!

Thank you! I've learned something new about the split function, so this was a good exercise. It was just unpleasantly surprising to see this test failure that I didn't expect.

The random tests in Python could contain trailing spaces, e.g. "24 4820 10380 21 259 1 "
I didn't expect this, and nothing in the description or the standard tests led me to expect it. It could be nice to add a specific test case for it.

The rounding requirement is a bit out-of-nowhere. Looking at the other solutions, a lot of users deal with it by multiplying the result by 1.0001 before rounding, or similar tricks.
Is that the intended answer? It seems less interesting and less correct than the version which sometimes returns 74.99999999999999 instead of 75.

If you want us to learn how to handle such edge cases correctly, it would be worth adding a few test cases that specifically check that. Where the correct calculation should give, say, 1455393541/1753486194, which is 82.999999998859%, and the correct answer would be 82. Solutions that simply add a fudge factor would give 83.

Thanks! I didn't notice the distinction between beta and draft.

I think I have a working solution to this kata, but it's a bit lopsided and I'd like to submit it so I can see what everyone else did.
It passes the server test cases, and a popup invites me to "take your time to refactor/comment your solution. Submit when ready." - but the Submit button doesn't show up. It still reads "Attempt".
I've not tried beta katas before, so is the process different for these?

It wasn't specified anywhere whether the input would always be single characters (e.g. some languages use // as a comment identifier, and we might want to support those!).
Stripping trailing whitespace also seemed like an odd requirement that wasn't clear at first.