Sorry, I meant static typing, not strongly typing. I often cross the two. But this is exactly what I mean, if you want something to be statically typed you have to put in the extra effort, if not you’ve got dynamically typing, which is fine when things are small but I find causes stumbling blocks when things get larger.
And depending on the scale of the project I’m working on, my unit tests usually take minutes to run, if not hours. If I’m debugging and I change a property, when I compile it instantly catches that I forgot to change it elsewhere. Hell, even when I save it I’ll get a little error warning. Maybe running unit tests all the time is fine if the project is small, but not if it’s large. I’m not going to run unit tests every time I’m starting a new debugging session. Linters kind of make up for this. But then we are back to making sure there are type hints, which, as I’ve been told, is not “pythonic.”
If people like it, more power to them, I’m not shitting on the language as even I like it. I just can’t use it for larger stuff, and I’ve never worked anywhere that uses it for larger stuff, and I think for good reason.
These exist in theory, but as a whole, I’ve never seen them working at even the base level of what you get in other languages.
Adding type hints to your code is fucking exhausting, because there is no type inference.
MyPy regularly calls it quits, when any library doesn’t have type hints.
PyCharm regularly doesn’t properly auto-complete, because it doesn’t have type information (if it can load your project correctly to begin with).
Unit tests exist, yes, but you need 100% test coverage to make the language properly check all code paths. Without it, even just calling a library isn’t guaranteed to work. In no fully statically typed language, would I recommend 100% test coverage, unless you have special correctness requirements.
Python was always strongly typed. For years there has been optional static typing and - you know - unit tests.
If you’re having significant issues due to not knowing what types you’re using, the type system may not be your greatest problem…
Sorry, I meant static typing, not strongly typing. I often cross the two. But this is exactly what I mean, if you want something to be statically typed you have to put in the extra effort, if not you’ve got dynamically typing, which is fine when things are small but I find causes stumbling blocks when things get larger.
And depending on the scale of the project I’m working on, my unit tests usually take minutes to run, if not hours. If I’m debugging and I change a property, when I compile it instantly catches that I forgot to change it elsewhere. Hell, even when I save it I’ll get a little error warning. Maybe running unit tests all the time is fine if the project is small, but not if it’s large. I’m not going to run unit tests every time I’m starting a new debugging session. Linters kind of make up for this. But then we are back to making sure there are type hints, which, as I’ve been told, is not “pythonic.”
If people like it, more power to them, I’m not shitting on the language as even I like it. I just can’t use it for larger stuff, and I’ve never worked anywhere that uses it for larger stuff, and I think for good reason.
These exist in theory, but as a whole, I’ve never seen them working at even the base level of what you get in other languages.
Adding type hints to your code is fucking exhausting, because there is no type inference.
MyPy regularly calls it quits, when any library doesn’t have type hints. PyCharm regularly doesn’t properly auto-complete, because it doesn’t have type information (if it can load your project correctly to begin with).
Unit tests exist, yes, but you need 100% test coverage to make the language properly check all code paths. Without it, even just calling a library isn’t guaranteed to work. In no fully statically typed language, would I recommend 100% test coverage, unless you have special correctness requirements.