Going to change it into a string once I have some spare time.

Rounding is one thing, but the place where potential problems are introcuded are calls to str(d). Stringification of doubles works in Python in a very specific way, and str does a lot of magic trying to come up with a very specific representation. This behavior is not inherent for IEEE-754 floats in general, and is not portable between languages (i.e. is not easily translatable). Without additional specification, users do not know that the reference solution uses str(d), and they do not know how to handle precision in a way considered correct by the tests.

The point is that there is no way of handling precision of floats, and representation of floats, which is considered "canonical". You made an assumption that the correct way is to use str(d) and rounding, but it is just one of possible assumptions, which is not universal. Without knowing this, users are missing some information necessary to come up with a correct solution.

Like natan said in the post above, float is not the best type to represent input for this problem. Something what represents "a sequence of digits" would be much better.

Python testing framework is not used correctly. Assertions at top level are not a correct thing, assertions must be called inside of a function decorated with @it.

You can see example kata or Python authoring guide for more info.

@PurrBunny

float does not represent decimal numbers. when you choose a type, make sure that it can encode the information you mean to convey.

if you consider it to be text, something you can write down, then the type for that is string.

some languages have a type to represent decimal numbers, that would kind of work, in that it's able to encode your values. however, what you're really conveying is the abbreviated number, not the number - so it probably shouldn't be a number type at all

if it is not text, but rather "many digits", then that's a list of integers

What is the result for d=.6?
And d=.5999999999999999222844?
And d=.6000000000000000333?

P.S. They are all the same number (0.59999999999999997779553950749686919152736663818359375 or 5404319552844595/2**53)

I have a workable solution by rounding everything. It is not theoretically 100% perfect, however practically there are no errors.

Its impossible to fix this issue and keep using floats. As long as floats are anywhere there, in solution or in tests, this challenge will be incorrect.

Fixed!!

Fixed!!

I think this is due to floating point shenanigans. I am looking into fixing this.

right and what about:
test.assert_equals(makeFraction(.27351), (183370381288423, 670427215036416))

why isn't answer (3039, 11111) ?

function name should be snake_case

test.assert_equals(makeFraction(.523681), (428417670197443, 818088190672896))

Why isn't the answer (523681, 999999)? That would produce the desired repeating decimal.

This solution should not work now that I have properly implemented the Tests.

Should be fixed now