I have noticed something peculiar about type hints in Python. Though they do provide readers of your code with a clear explanation of what type of object your function/class will give when some input is passed, they don’t really DO much in general.
In fact, a simple docstring below the function definition (the def line) can easily describe the type of object your function/class will give when input is passed the same way as a type hint.
My Proposal:
If type hints are somehow useful in any core part of Python, at least a check should be passed by the Python parser when a type hint is given to make sure that the function returns the same type as shown in the type hint.
Or, if they are not useful, why can’t we just remove the type hint facility entirely?
(And if it turns out neither of these proposals are useful, I will take my words back. Also, below, I have provided proof that it simply doesn’t matter (as of now) what type is described in the type hint.)
Type hints are useful if you use a static analysis tool like mypy. They are also used in libraries like strawberry. They are not designed to be checked at runtime or compile time by the interpreter.
The thing is, not many people who are beginners in Python (like me) use Mypy and Strawberry. so I never knew type hints are used in libraries like these.
Not having this is actually by design; checks like that would make programs run slower, so we use “static analysis” tools (mypy et al.) for that instead. That way, you get safety by running a static type checker before running the code, then completely ignore the hints to save time as you run the code.
A typical workflow might look like this:
Write your code.
Debug your code.
Run a type checker on your code (fast).
a. If that fails, to step 2.
Run traditional tests on your code (slow)
a. If that fails, to step 2.
Deploy your code.
Wait for somebody to report a bug (slow).
a. If that fails, back to step 2.
Static tools are designed so to report type-hint errors at step 3, even though they don’t “do anything” later on; hopefully, you can see how that can save time. In fact, they can save even more time during steps 1 and 2 through IDE extensions and the like, which will often underline your code in red as soon as they see a type error.
That’s also a little bit by design! You don’t need type hints when you’re a beginner; in fact, they can often get in the way by:
“Forcing” you away from dynamic patterns, which is a by-design aspect of Python.
“Forcing” you to write type hints, which can take time away from trying to learn.
Type hints tend to exremely valuable in big projects or once you’re already familiar enough with the language that they’re not a burden, but until then, they’re not the #1 priority.
As already said in previous comments, for simple scripts and small projects that don’t go beyond a few modules, type hints don’t bring anything particular to the table - especially if they’re meant to be used in self contained environments. The perspective completely changes when projects grow in size consistently.
Additionally, type hints have become a powerful tool to embed metadata information about object types that go beyond the scope of simply saying “this is a str type”.
Just look at pydantic or fastapi and their documentation. They’re two of the most popular python packages out there which can be used both for simple scripts as well as big, scalable projects. In particular the documentation express the importance and ergonomics of type annotations, such as using typing.Annotated in fastapi
I think its important to have hints of you’re a library writer, not so much if your just blasting out quick scripts. I spent a great deal of time generating stubs for my library, also use ruff and mypy.
a check should be passed by the Python parser
On the fence; I wrapped Python for AutoCAD, there’s zillions of class hierarchies, functions that take a PyObject, or can accept iterables… seems a static analysis tool would be better than bogging down the parser.
