My fear is that this type hinting pushes #python down the same bad road as #cpp:
Making an originally nice programming language more and more complex and ugly by giving in to the pressure of adding more and more features which don't fit into the original idea of the programming language.
In my view, the core philosophy of #python is that it is a high-level dynamically typed language . And the core philosophy of #cpp is that it is a low-level statically typed language.
Don't mix that.
But you don't have to use type hints at all, even in the latest versions. They're completely optional. You could write an entire new application without a single type hint in it, and it would work just fine. Static linters like mypy wouldn't be able to find as many problems without the hints, but that's a tradeoff.
Or does it somehow bother you when some #dependency has type hints in its code?
Fair point; the code becomes more visually complex. For a beginner, that probably makes a difference.
On the other hand, using type hints saves so much developer time, since bugs are easier to catch, especially with static type checking tools. So adding hints to a project's codebase makes the existing developers more productive.
I suspect that any new dev wanting to contribute to a project will be past the point where hints hurt their participation.
@cazabon @kevin @folkerschamel @ado we're writing an integration for a complex #python behemoth that is spread over many dozens of repos, packages and layers of abstraction. The documentation is insufficient. If they at least had type hints, I would have a much easier time untangling how everything is connected.
Things should be as simple as possible, but not simpler. I hate code where I have to do detective work to see what kind of object I get. I think you're wrong about types.
@zenforyen @cazabon @kevin @ado
#python type hints as "better than no documentation at all!"
Interesting take, didn't think about that.🙂
@folkerschamel @cazabon @kevin @ado that's just to give you a very non-theoretical example.
If you do it right, types are succinct, machine-checkable documentation and safety rail. Because they are optional in python, I can escape them to do dynamic magic that mypy has no chance to follow. It does not have to be perfect to be immensely useful.
And you can avoid creating+maintaining trivial sanity-check tests or isinstance guards in code for things mypy can see and warn about.
@folkerschamel @zenforyen @kevin @ado
Actually, I think that #type #hints in the #function #signature are usually *better* than having them in #docstrings. Not only can they not get out of date / become wrong (without causing checking failures), static type checking is much easier this way.
@cazabon @folkerschamel @kevin @ado even automatically generating nice documentation is better that way. mkdocstrings or pdoc can easily pick the type hints up, make things clickable etc. Without any extra manual effort.
Docstrings should be about the things a tool can't check, not for telling me that it's supposed to be some object following some interface, hidden deeply in a paragraph of text I don't want to read to get that info.
Btw, #Python Protocols are great for lightweight interfaces.
@zenforyen @cazabon @kevin @ado
I see the abstract arguments. But I would love to see a specific example where type hints helped.
Also in our own projects, I don't remember a situation where I thought "yes, we could have avoided trouble here".
In contrary, reading source code like of https://docs.sqlalchemy.org/en/20/core/engines.html#sqlalchemy.create_engine was always more cumbersome than e.g. https://docs.python.org/3/library/urllib.request.html#urllib.request.urlopen.
In my experience type hints take away the ease of #python which intentionally makes it different from #cpp, #java, #golang.
@folkerschamel @zenforyen @cazabon @ado This is a small example and a bit of a shameless plug, but check out my jinjanator-plugins project on PyPI and one of the format plugin projects.
Type hints are not mandatory for plugins to that tool, but the API is fully type-hinted and during development this helped me ensure that the plugin code was doing the right thing (returning a mapping of string keys with function values where the functions have the correct shape).
@kevin @zenforyen @cazabon @ado
Do you have a specific sample what kind of problem you caught during development via type hingts in such a way that it saved you trouble or avoided problems down the road later?
Maybe our situation and code base is just different (maybe https://mastodon.social/@folkerschamel/110881640133119780, https://mastodon.social/@folkerschamel/110881535040074008).
Or maybe I miss something and can learn from it.🙂
@folkerschamel @zenforyen @cazabon @ado The problems found by static type checking would have also been found by unit testing, but they were found earlier and with detailed explanations of the type mismatch.
This saved me the time required to troubleshoot failing unit tests.
In this case the API involves a function returning a dict of functions which themselves return dicts, so it's quite easy to accidentally invoke the final function instead of the intermediate one and think you have done it correctly.
@kevin @zenforyen @cazabon @ado
What I definitely see is that static type checking finds bugs at "compile" time before even running your code (whether it's unit testing or just running it yourself). That's for sure an advantage of statically typed languages (and we use for example #cpp a lot). But in practice I don't saw a significant difference here.
Maybe refactoring would be the biggest difference.
Folker
C.
Kevin P. Fleming
zenforyen