The funny example is that the hasattr built-in just tries to getattr, and then catches the exception to tell if it has the attribute.
https://docs.python.org/3/glossary.html#term-EAFP comments:
> Easier to ask for forgiveness than permission. This common Python coding style assumes the existence of valid keys or attributes and catches exceptions if the assumption proves false. This clean and fast style is characterized by the presence of many try and except statements. The technique contrasts with the LBYL style common to many other languages such as C.
and there are any number of essays on the topic, like (random DDG search) https://programmingduck.com/articles/lbyl-eafp .
The fact that the language doesn't have your back means you need to be more careful about types, not less. The type of the arguments is a function precondition. It's the callee's responsibility to document preconditions and ideally recover cleanly from a violation, but the caller's responsibility to ensure preconditions are met. Illegal states should be caught early, not allowed to percolate until an exception is thrown.
I don't much care if what I just wrote is "Pythonic" or not. I don't think too much careful design up front is responsible for every Python codebase I've ever seen reading like Finnegan's Wake.
I dunno. I don’t love Python for big projects either. If we want to go around and tell all the people using this very popular language to stop shipping their successful products because they look messy to us, I’ll happily take the second shift (after you), haha.
If there are situations where you have no choice but to drive without airbags, those are holes in safety.
Essentially if you have to have runtime checks to prevent the program from full on crashing those are holes. Not everything is checkable with static checks but the way to go is to move as much of your code away from runtime checks as much as possible.
So for opening a file for example, using try/except instead of checking if the file exist and is readable first.
Both achieve the same results but the first is more "pythonic".
My point is that this way of writing code is not at all incompatible with using a type checker for said code.
I'm saying "incompatible" isn't even a relevant concept here. Here's an analogy:
You're telling me that running with shoes is compatible with running without shoes thus I can run with one shoe on one foot and the other foot is barefoot.
The goal is to objectively put shoes on both feet. Sometimes you're missing a shoe so you have no choice. But this has nothing to do with "compatibility" it's a completely different thing.
We are getting a bit into pedantic territory here, but THAT was my point and I am simply clarifying it because you MISSED the point.