I mean thats one of the big points of python and why you wanna use it in the first place.
I personally don't main python but to me this all seems like a effort to retrofit the language for use in large enterprise and web applications, something for which it honestly never should have been used this heavily in the first place. I guess the state of the world 10 years ago let to it, with .NET not officially being multiplat, Java being Java and Rust, Kotlin and Go being in their infancy.
To me Python always was a cool language to write small scripts to automate certain things. Something a single developer writes with < 10K LoC. Where than you can achieve the same thing with way less code and less hastle like setting up a seperate build tool
If your gonna go heavy on typing and error handling but don't want the complexity of a compiled language just use a .NET or JVM lang, honestly. They are fundamentally built around strong typing and use that information for much better performance and developer experience.
Or if you just want THE most flexible typesystem where you can specify types as broad or specific as possible typescript takes the cake.
I write Python and Typescript with full typing for my day job, and it's pretty nice. Here's the general workflow:
Add some code without typing
Iterate on 1 until it works properly
Add tests and types
Submit code for review
In development I get the benefit of most of the types being specified, but I don't need to specify everything until I'm done. I much prefer Python to Typescript, but my hands are tied on the FE.
If I needed better performance though, I'd write in Rust, which is actually what I use for most of my hobby projects.
Same goes for the try/catch exception system where runtime errors can pop up bc you don't have to handle exceptions
I see three possible ways to go about errors:
Make the programmer actually handle (not just bubble up) all possible errors, which will at some point break abstractions and make writing any piece of code an exhausting task.
Make it easy for programmers to ignore errors silently. The worst option IMO as it risks undefined behavior and creates bugs that are hard to replicate.
Make it easy to surface errors to the caller and halt the execution if unhandled. This is what Python exceptions do and I believe to be the best compromise. Bubbling up errors is given by the language and does not depend on the programmer's willingness to check for errors like in Go (also no err != nil checks all over the codebase).
The criticism I have to Python exceptions is that there should be a way to explicitly see the exceptions a function raises, maybe as part of the function signature like in Java.
To put it another way, I don't think errors as returned values are immediately better than exceptions. I like the way Rust handles them for instance, but an unsuccessful .unwrap() is not that different from an unhandled exception. I just wish the possible exceptions raised were explicitly stated.
I feel like Python is coming to its senses in the recent years, with releases focusing on typing constructs and the match statement. I think they're on the path to be a great statically typed language, don't you think?
Python lets you add static type annotations to your program, so you can say "this variable should be and int or a string", and that means Pyright (a fantastic static type checker) can tell you if you screw up and forget that it might be a string.