Exercise: Time to Jupiter

For this exercise, would it not be more consistent to carry the values and their units into and out of the function as follows?

from pint import UnitRegistry

ureg = UnitRegistry()
Q = ureg.Quantity

def travel_time(distance, speed):
    """Return the travel time as a pint Quantity in seconds."""
    return (distance / speed).to("sec")

distance = Q(670_000_000, "km")
speed = Q(35, "km/sec" )

tof = travel_time( distance, speed )

print( f' \n distance    = {distance}' )
print( f' speed       = {speed}' )
print( f' travel time = {tof}' )

@Orbital Mechanic you’re right that it reads more consistently, and your version does give the correct answer:

>>> travel_time(Q(670_000_000, "km"), Q(35, "km/sec"))
<Quantity(19142857.1, 'second')>

Passing quantities in also means the function stops assuming kilometers and km/s, so travel_time(Q(416_000_000, "mile"), Q(78_000, "mph")) works just as well.

The one catch is the exercise’s tests, which call travel_time() with plain numbers like travel_time(670_000_000, 35). With floats coming in, distance / speed is still a float, so .to("sec") raises AttributeError: 'float' object has no attribute 'to'. That’s why the requirements have the distance arrive in kilometers and the speed in km/s, with the unit bookkeeping happening inside the function.

You can have it both ways, because Q() passes an existing Quantity through and converts it if needed:

def travel_time(distance, speed):
    """Return the travel time as a pint Quantity in seconds."""
    return (Q(distance, "km") / Q(speed, "km/s")).to("sec")

That handles plain numbers and unit-aware inputs:

>>> travel_time(670_000_000, 35)
<Quantity(19142857.1, 'second')>
>>> travel_time(Q(670_000_000, "km"), Q(35, "km/sec"))
<Quantity(19142857.1, 'second')>
>>> travel_time(Q(416_000_000, "mile"), Q(78_000, "mph"))
<Quantity(19200000.0, 'second')>

And it still fits in one return, so the single-expression bonus test stays happy :)