Missing the point of loose languages

Exactly my feeling!

Python was (still mostly is) so clean and at the same time powerful enough for all my use cases (data analysis, glue language for numerical codes). And just perfect for teaching introductory classes for scientists.

I highly welcome a generic type annotation system that codes like Cython make use of. But imposing a mandatory rigid typing system is the wrong approach. If strong static typing is needed, there is a big choice of other languages out there (go, rust, C++, Java, Haskell, ....ML).

But of course, this also comes with a high cost. Besides the need for compilation, for C++ we have the Design Patterns (Gang of Four) with Facade, Adapter, Decorator patterns etc that are not necessary in Python because of Duck-Typing.

For me Python is getting less and less attractive if more line noise is added, and simple code is becoming unreadable. From a comment above

def foo(a: object, b: type[T]) -> TypeGuard[T]:

does not look and feel like Python anymore. Why not use Haskell right away?

I hear you, but then I had to deal with upgrading some email lib from 2 to 3 which was mixing bytes and strings and it was so much easier to do in stages by first annotating the functions with types, and fixing mistakes, then doing the py3 upgrade.

Until I started annotating with types, I was dealing with "Oh, that's a bytes regex, doesn't work on str", on line xxx. And other errors, where as being careful and making sure the encoding/decoding happened exactly once, and using the types to check that across all the functions and not playing wack-a-mole with errors is so much nicer.

And when I'm working with pandas, I do want to know if I have a DF with only one column vs a Series, as the operations are different, but it's just `df['col'] ` vs `df[['col']]` to get each one. (I think). So I already need to check and keep the types separate, why not ask the compiler for help?

Erlang is one language where the type system was added later. In my experience it's most useful for documentation - now there's a standard way to specify the type of the arguments in an API function. There's a tool (dialyzer) that checks for type errors: I worked on a project where the type annotations were added on later, about 95% of the errors it found were in dead code (so not covered by unit tests - one such example was a branch that only executed if the current date was before 2000, and we were adding the type specs in 2010). If there is a decent test coverage, there's little (but not zero!) value the type system can add.