Many people in the Python community simply aren't writing those kinds of applications. They're writing applications where typing is not a benefit, it's a hindrance, so they don't use it, and Python makes that easy.
But often it can be helpful to know the shape of the input and the shape of the output. Eg are we working with a 2D,3D or ND array.
Before 3.11 it was not simple (possible?) To type this. But https://peps.python.org/pep-0646/ makes it possible. If somewhat clunky on the definition side.
This is not to make the general claim "Typing is a hindrance in parsing applications", or anything close. It's saying "the current static type system(s) available in Python would have made this Python library much worse".
Many of us in the python community know the benefits, and we’re simply changing our stack so python is as contained as possible, and dropping lower quality libraries for higher quality typed ones.
And Python has a ton of newbies, college kids etc. Though this is also true of JavaScript.
As an industrial language/environment with best practices for very large codebases, it's really weak and I much prefer TypeScript despite the occasional tooling fatigue (has slowed down).
But a ton of money has been poured into JavaScript (v8) which really set that into motion.
There isn't a benefit to static typing in Python, it's a massive drawback.
I hate "Citation needed" comments, but this is a very strong claim and so deserves it:
Citation needed
It's like Youtube reducing bandwidth in streaming videos, a better compression algorithm can't compete with simply asking the end user if they are stilling watching the stream.
As a matter of principle, I won't provide citations unless you first provide some citation that says I'm wrong first. (You won't find one)
It is a strong claim, it's also a very precise claim. Where do your numbers come from?
Haskell and the ML family of languages also permit you to write much more concise programs than many other languages and they're definitely statically typed. How do they fare in your imaginary analysis?
> As a matter of principle, I won't provide citations unless you first provide some citation that says I'm wrong first. (You won't find one)
Ok, so you're an idiot. Got it. You can't make such a strong and precise claim and not back it up, and try to turn the tables by saying "No your citation!". You just come off like a petulant child (maybe you are?). Your claim makes no sense, and anyone who has at least 5 years of experience (probably less, actually) would know that.
You've asserted there are empirical studies on the topic to back your numbers. Just provide them.
Well I don't know since I haven't read studies about Haskell and the ML family of languages. I suspect good things about Rust's borrow checker but I still don't know for sure.
I don't believe it is a strong claim. That's entirely in your head. It might not be a claim you like but that doesn't make it a strong claim.
So provide a citation saying something different to what I'm saying and I'll provide my citations. You have asked for a citation, so the first thing you can do is provide one of your own. Come on, you can do it! (Hint: You can't)
If it really was a strong claim, you could disprove it easily.
When I go looking for myself what I found was studies saying that dynamic typing reduces development time by 2.5x and bugs per software feature by 2.5x.
So perhaps one of these people claiming that static typing reduces bugs over dynamic typing, could provide the slightest bit of evidence to backup their claims?
Is that too much to ask @spoils19?
But I'm pretty sure they will just find the exact same figures as me.
I think it's more effective to show that there is no evidence to contradict me first.
He also misses the biggest add of typing your code which is that other people can understand it better. This is often lost on junior programmers...
See: "Work In Progress: an Empirical Study of Static Typing in Ruby; Daly, M; Sazawal, V; Foster, J."
See: "Haskell vs. Ada vs. C++ vs. Awk vs. ... An Experiment in Software Prototyping Productivity; Hudak, P; Jones, M."
Lisp - A dynamically typed language had the lowest development time by a factor of 2.5x. Seems to be the same figure I'm giving, fancy that!
"He also misses the biggest add of typing your code which is that other people can understand it better."
Nope.
See: "How Do API Documentation and Static Typing Affect API Usability? Endrikat, S.; Hanenberg, S.; Robbes, Romain; Stefik, A."
You need documentation and whilst Java students may study with dynamic typing since they haven't been taught it, it's pretty clear that on it's own static typing provides almost no useful documentation.
"This is often lost on junior programmers..." I'm far more experience than you, which is why I'm calling out the BS.
I think you will find that the research suggests that static typing and dynamic typing have a similar bug rate per line of code.
See: "A Large Scale Study of Programming Languages and Code Quality in Github; Ray, B; Posnett, D; Filkov, V; Devanbu, P"
Once you combine that knowledge with the knowledge that dynamically typed programs have less lines per feature.
Relational Lisp 274 compared to Ada 767 or C++ 1105.
Dynamic typing wins out because the programs are smaller, making them faster to write and contain less bugs per software feature.
The link you posted confirms it.
Do you understand that you are wrong?
Here's my much better argument: Instead of using dynamic typing, eating babies reduces the incidence of bugs in code by 1000x. If you don't believe me and would like me to cite a source, you first provide a citation saying something different to what I'm saying and I'll provide my citations. Come on, you can do it! (Hint: You can't)
If it really was a strong claim, you could disprove it easily.
It's not bad faith because you don't like the arguments conclusions.
I'm sure you can, right?
Also, we've been using non-standard type hints for nearly all of python 2, they were just non-uniformly specified in docstrings and weren't easily referenced or introspected for tooling and IDE's to work with them.
We had an entire history of Python 2 without type hints. Why use them now?