Everyone doing Python nowadays is aware Python supports optional type hints, and has for some time now. This has created a small schism in the community, with some people being completely uninterested in type hinting and a little defensive about the language partially going into a new direction, some people being very exciting about the potential of our evolving type tooling, and the vast majority of folks in the middle, not entirely sure where and how to apply type hinting best. I am of the belief that currently, Python is actually two very similar programming languages sharing the same name. This certainly isnt a surprise to anyone whos been using Python for a while. What might be a surprise, though, is that I think this is actually a good thing. The languages, lets call them untyped Python and typed Python, even though sharing a very large common base are fundamentally different in how they enable the developers using them to solve problems. Allow me to propose a model of thinking about code: theres infrastructure code and theres business logic code. Infrastructure code is exciting, powerful code that exposes easy-to-use interfaces that solve difficult and tricky problems, like talking to browsers (Flask), talking to databases (the Django ORM, SQLAlchemy), dependency injection frameworks (incant), serialization (cattrs) or defining classes (attrs, dataclasses). Business logic code is boring and unexciting code that enables you to solve problems and finish tickets and sprints at your day job. The point of infrastructure code is to enable and empower business logic code; business logic code provides the actual value to your employer, your users, or whomever is using what youre writing. Infrastructure code is the libraries youre using, business logic code is the code you yourself write and deploy. (Note that this way of thinking about code is, like all abstractions, leaky. A library that you use may be a simple layer between other libraries and hence have all the characteristics of business logic code. If youre employed at a typical software developer position your work codebase will, almost certainly, have pieces of infrastructure code in it that youve written for that codebase. Even so, I find this way of thinking about software is very useful.) It is usually impossible for infrastructure code to be fully type-hinted internally; the Python type system isnt, and probably never will be, powerful enough to support the types of operations libraries like cattrs and attrs need to do. This makes sense; one of the greatest strengths of untyped Python (and what brought me to Python in the first place) is that the infrastructure code available can offer amazingly friendly and powerful APIs. So untyped Python is, and has historically been, great for infrastructure code. Untyped Python is not very good for business logic code, which is why historically software developers have been quick to complain about maintaining large systems written in Python, and with good reason. Business logic code is usually much simpler than infrastructure code, and theres a lot more of it in the world today; for each SQLAlchemy or Django, there are probably hundreds, if not millions of codebases actually usin
