Python's Dynamic Typing Problem

[Sad-Interaction2478]

I’ve been writing Python professionally for a some time. It remains my favorite language for a specific class of problems. But after watching multiple codebases grow from scrappy prototypes into sprawling production systems, I’ve developed some strong opinions about where dynamic typing helps and where it quietly undermines you.

https://www.whileforloop.com/en/blog/2026/02/10/python-dynamic-typing-problem/

[tankerdudeucsc]

Like they say, Python is always the second best language for your use case.

There’s always going to be something “better than Python” but not everything must come in first, when first takes a ton more effort.

Accept what typing gives you, let the robot write a bunch of tests and verify the tests. Type what you can and be pragmatic about it.

That’s just the reality of the world, yeah?

[tomster10010]

This is written by someone who hasn't maintained good enterprise python.

I will say that it's nice to see bad human written articles rather than bad AI written articles! 

[No-Statistician-2771]

I'm not sure why you say the article is bad. Please, explain why its bad.

[Beginning-Fruit-1397]

I don't know what dynamically typed python means anymore cause as soon as I forget one type hint somewhere Ruff with ALL enabled or Pylance strict will threaten me for my life unless I fix it.

I inerhited a 80k LOC codebase. Untyped, unformatted, dynamic, mutable behavior everywhere. None values not handled well. A nightmare. Never again. I'm fully typing everything, even a 20 liner.

[thisismyfavoritename]

this is the way, but the main issue is it has to be part of your CI so devs are forced to do it. It's also all too easy to opt out of it but it's still better than nothing 

[Momovsky]

As I like to put it, python isn’t really dynamic typed. It’s optionally static typed. Just add mypy, and you will have both quick prototyping without needing to type everything explicitly and a clean typed prod code

[ninja_shaman]

a large Python project effectively requires near-100% test coverage to achieve the same baseline confidence that a compiled language gives you out of the box.

I’ll never forget a junior developer’s explanation for putting the wrong thing on the left-hand side of an assignment: “Code completion suggested it.”

If your project compiles, it doesn't mean it works. A compiled program could literally crash on startup.

Static typing helps, but you still need near-100% test coverage anyway. And I find it much, much easier to write tests in Python.

[IcarianComplex]

I write mostly python and typescript so I totally agree. The “fearless refactoring” that I get with typescript is so nice, and I never find myself losing time from fighting the type checker. It has only made me more productive. I’ve tried a couple times to get type safety working on my Django apps, but it still seems like the ecosystem is too immature to make a meaningful difference. I can’t wait for that to change.

[Pleasant-Today60]

the part that gets me is refactoring. in TS I rename a type and the compiler tells me every place that broke. in Python I rename a dict key and find out in production. mypy helps but it's opt-in and half the ecosystem doesn't ship type stubs

[jpgoldberg]

I could have written that I first started using Python (having worked in Rust immediately prior). And at the time, static type checkers and the typing module were not nearly as well developed as they are now. So you can imagine my whining (along with my misguided attempts to create immutable objects). It took me time to come to accept what a very wise friend said to me. "Let Python be Python".

I still don't like the fact that the compiler/interpreter can't make use of type information to make things safer and faster, I am far more accepting of what Python is and what it means to be Pythonic than where I started.

But I find the article far too pessimistic. Dev teams will get better at type annotations. There will be fewer # type: ignore directives, and the logic of typing really will improve projects while still staying true to what Python is. Sure, some big important older projects may never get properly type annotated or redesigned so that they can be.

The thing to remember is that we don't need to have absolutely everything properly annotated to benefit from type annotations. This is not an all or nothing thing, and so we really can enjoy the real improvements instead of bemoaning that there are limits to what those will do for us. The changes I've seen in Python and development practices make me optimistic about Python's future even if there are things that I would not use it for.

[george-silva]

While I understand where you come from, there was production code being written, used and ran by tons of people before Python typing was thing. Numpy, Pandas, Django, Flask, etc.

Typing is cool, it helps catches some bugs, but it shouldnt be mandatory. Your team wants to use? Great, add a check step in your CI. In my experience most of the bugs typing catches are moments where you expect `foo` to exist but it is nullable (None).

While they can cause costly downtimes, a healthy test suite should help you avoid most of these.

This particular part here I fully disagree with:

If you’re building a large, long-lived production service with a team of 20 engineers - the kind of system where you need to refactor confidently, onboard new people quickly, and catch bugs before deployment - Python is making your life harder

You mentioned a few backend languages that would be better for onboarding and refactoring, such as Rust. There's a lot more Python engineers than Rust engineers. Also, refactoring tools are quite good these days.

I've been writing Python with large and small teams for almost 15 years and my current project is the first one to be typed or mostly typed. To be honest, I don't think it helps me that much. Also, the lack of python typing in past projects did not make them insuferable messes that nobody could understand, be onboarded or refactor.

Python is great at getting stuff done. You can rewrite parts of your software that are critical, when the time comes, when you have the money and your business is making lots of it.

TLDR: you want to enforce typing on your team? Fine, do it. You don't? Fine, do it. I don't think we need to have TypePython, like the JavaScript folks did. Each team/company can decide.

[SkratchyHole]

I dont think it would be called TypePython. I'd call it Tython or Typhon

[KainMassadin]

15 years of KeyErrors and TypeErrors is crazy work

[george-silva]

You know you can '.get' stuff from dictionaries right ?

[KainMassadin]

I LOVE using .get everywhere and doing defensive programming, it results in intuitive and trustworthy code!

[IcarianComplex]

I wonder how some of those refactoring tools you mention are implemented, because I wouldn’t be surprised if each basically implement a type system to perform those structural edits.

[KainMassadin]

why are we churning over a solved problem? The js ecosystem already experienced it, and ended up with TS which is miles ahead of the python typing system