That needs to be explicit for any interacting types. You must define separate classes and explicitly define their hierarchy. This is fine if you control all the types, but it breaks down quickly. The best example is having two TypedDicts with the same members; in Python, you cannot use one instead of the other.

    from typing import TypedDict

    class A(TypedDict):
        a: int
        b: str
        

    class B(TypedDict):
        a: int
        b: str
        
    def f(a: A) -> None: pass

    b = B(a=1, b='b')
    f(B) # mypy error: Argument 1 to "f" has incompatible type "type[B]"; expected "A"  [arg-type]

On the other hand, this is legal in Typescript:

    interface A {
      a: number;
      b: string;
    }

    interface B {
      a: number;
      b: string;
    }  

    function f(a: A) {}

    const b: B = {a: 1, b: 'b'};
    f(b);

This is most useful when A has a subset of B's attributes, like this (which also doesn't work in Python):

    interface A {
      a: number;
    }

    interface B {
      a: number;
      b: string;
    }  

    function f(a: A) {}

    const b: B = {a: 1, b: 'b'};
    f(b);

That seems a lot like duck typing to me.

Yes, it is. Typed Python supports duck typing to some extent; see typing.Protocol and stuff like Sequence, Iterable, Mapping, etc.

I'd argue non-typed Python supports duck typing pretty well too, so you don't necessarily need Typed Python to support it.