In my experience, type errors in Python get discovered during testing. So, I doubt that's the reason.

Perhaps the nature of Haskell discourages changes, making the community more stable.

> In my experience, type errors in Python get discovered during testing

That would be the optimistic view. In reality, `NoneType has no attribute Foo` errors happen in production all the time.

Perhaps because someone got into the (bad) habit of returning Nones instead of raising errors. Errors should never pass silently, etc. The older Python APIs have that C habit of sentinel values, but more modern style is to raise an error on failure.

Functions implicitly returns None if you forget to provide a return value on any of the branches. This is an error that can easily slip past eyeball reviews, since this is caused by the absence of something.

Shouldn't unit tests be exploring all the code paths? I know that's tough to enforce, but it's ideal. Regardless of whether you use a static analyzer.

And Python does have static analyzers, including for typing.

I don't think it's strong types either. It is not about the libraries having less bugs, but about they keeping compatibility for much longer (and when they break it, they tend to break in smaller ways).

Could be because of extra flexibility those types grant you, but it's not about bugs.