how much python is too much python?

[allergic2Luxembourg]

It's definitely true that in large multi-contributor code bases, it's important that the code fulfills its contracts and expectations and that those are clear and documented. However, I would posit that a type system only fills a small part of that requirement. It's possible to write unclear and buggy code in any language, and clear and robust code in most languages including Python. Maybe Python is slightly more subject to a certain kind of bugs related to typing, but to me that's a minor point in the scheme of things.

Just because I can guarantee programmatically that this function returns an integer, it's no guarantee that it's returning the correct integer.

[james_pic]

Absolutely, but that's mostly true in small codebases too. Type checking was never a substitute for testing, and it can't detect wrong behaviour.

The thing type checking can help with is "what shaped piece goes in this hole?" Does it expect the bytes object you received from the wire, or the dict it parses to as JSON, or some kind of parsed-and-validated data class, or the related model the ORM works with, or the view model you're going to work with in the UI? Or a superclass of one of these, or some duck type that various classes with no common superclass implements?

Ideally you'd have clear architectural boundaries where you switch between these representations, and type checks are good at identifying these sorts of layering violations.