[jonathaneunice]

Sure you could just use in-program comments and/or external annotation files. There were a handful of standards for doing exactly that... NumPy, Google, RST/Sphinx, Epydoc, Zope, ...probably a few others I'm forgetting. And there were external "stub" definition files like `.pyi`. Not exactly code, but closely-linked metadata. Ruby seems to be trying something like that with its `.rbs` files.

IME not until there was a sufficiently clean, direct, and common way to add typing (PEP 484 and its follow-ons) did the community actually coalesce, standardize, and practically start to use type information on a broad basis. We needed there to be one default way of sufficient attractiveness, not 14 competing, often incompatible, and rather inconvenient options.

You may look at built-in typing as a way to communicate with interpreters, compilers, type-checking and linting tools, and/or editor language support engines. Certainly the old purely static typing languages looked at them this way, out of necessity. The compiler, linker, loader, ABI chain has to know the bit-width of your objects, and pronto, because they're going right on the stack!

But in a highly dynamic language that doesn't strictly need types to run the code, typing works as much a signal to future me and my colleagues and collaborators as it is to any mechanism or tool. It signals structure and intent that we'd otherwise have to intuit or decipher. That some tools can use it too, just as they do in fully static languages, is great and useful but not the whole enchilada.