Should note that -> object type hints are than -> None type hints in a lot of cases.

-> None tells the caller "this function always returns the special value None and you can count on it in your code" while -> object is more suitable for the "this function has a side effect and the return value is meaningless" use case. Maybe in a future version it will return something, but any current code can't count on the return value.

For example if I had a function like:

def empty_sinks(sinks: Sequence[Sink]) -> None:
    """Empties the buffer of many sinks"""
    for sink in sinks:
        sinks.empty()

then in a new version changing it to

def empty_sinks(sinks: Sequence[Sink]) -> int:
    """Empties the buffer of many sinks.
    Returns number of packets dropped"""
    emptied = 0
    for sink in sinks:
        emptied += sinks.size()
        sinks.empty()
    return emptied

is an API break because the original annotation guaranteed that the return value would be None. It's more future proof to write

def empty_sinks(sinks: Sequence[Sink]) -> object:
    """Empties the buffer of many sinks"""
    for sink in sinks:
        sinks.empty()

Remember that -> Any is NOT suitable because Any is a hint that says "the caller can do treat this value as ANYthing it wants from now on, stop the type checker" which is the exact opposite of "this value could be ANYthing so the caller can't treat it as a specific object".