Ah, so the answer to "do you interact with scientists" is no, even though scientists are responsible for a huge amount of the python code that exists. Got it, maybe consider that your experience isn't universal.
I don't know why you think dismissing legacy code is valid! More code is old than new in the world, and the idea that you're only going to run into codebases with the most up to date versions of software seems pretty naive to me.
Serverless runtimes have historically been behind on Python versions, Airflow had a hell of a time with dependency issues and Python 2, etc etc.
I also don't really care whose fault it is - the question isn't "is Python morally wrong", the question is "can I rely on the technology that you offer as the solution to a problem as being actually used by the community and therefore actually a viable solution to the problem." Python type annotations are not popular.
> I don't know why you think dismissing legacy code is valid!
Because everyone everywhere has legacy code. In that sense, Python isn't split between versions any more than any other language, making that statement moot.
If you want to use type annotations, you can, for years now. If you want to use macros to generate macros in Rust, you can, it's not Rust's fault if you're stuck on 1.20 and don't want to upgrade.
I agree that all languages have legacy code, that was sort of my point :)
> If you want to use type annotations, you can, for years now.
Yes! And it's a cool feature. Can I expect most libraries to provide types so that I know I'm calling them correctly? Is it going to be an uphill battle for my team to use them, because the community at large doesn't find them necessary? The default for a majority of Python codebases is to not use types, and that's totally fine, but that also means that rather than type annotations solving the super-grand-OP's concern, they're going to potentially add friction.
It's likely, and that's FINE, that you're going to be in dynamic-land when you're working in Python, due to the preferences of the community, and it's cool that you can use annotations if you yourself want to get some nice signature checking.
But you don't need the libraries to have type annotations for them to be useful to you. You can use the libraries' classes as types, and type signatures are already very useful even if you only use them in your code. I agree that they will be even better when morelibraries declare them too, but I find that type annotations are a huge benefit in my own code either way.
I think we can agree on that - my point primarily is that:
1. In my own code, they are super helpful
2. I still get really frustrated when I'm calling other libraries (I had this experience when the various typed JSes were fighting it out as well) - in fact for a lot of web-style work that I do MOST of my code is calling a library, which is where I'd get most of the value.
Sure, I agree with that. More libraries supporting types would be great. I don't know why they don't, it's not like they need to support any Python versions that don't support types... I guess most just haven't gotten around to it.
I don't know why you think dismissing legacy code is valid! More code is old than new in the world, and the idea that you're only going to run into codebases with the most up to date versions of software seems pretty naive to me.
Serverless runtimes have historically been behind on Python versions, Airflow had a hell of a time with dependency issues and Python 2, etc etc.
I also don't really care whose fault it is - the question isn't "is Python morally wrong", the question is "can I rely on the technology that you offer as the solution to a problem as being actually used by the community and therefore actually a viable solution to the problem." Python type annotations are not popular.