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.

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:

1. 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.
2. 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.
3. 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.

There are various ways to monitor and handle types, they just aren't set up right out of the box. It's not uncommon for a language to be greatly enhanced by libraries/extensions. Having a robust development environment and standards are just part of writing good code.

This is not an apology for python not having it all out of the box, I think it should. Some things.just take setup and for now thats how it is.

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.