A surefire way to make your Python code terrible. The whole point of Python is the duck typing. If you're not going to use that then you might as well use a real programming language.
Code, like the one provided by the OP, should be valued and encouraged to prevent future bugs. Incorporating tools like Mypy during pre-commit and pyright during code editing can make a significant difference. This approach helps eliminate the need for writing unnecessary unit tests that check for None type.
In my opinion, as a mid-senior developer, I always appreciate the use of types in Python. If you are confident about having predictable inputs, you can rely on duck typing and use it primarily for scripting purposes.
Yep - or it's the standard for some tasks & the important thing is being able to use the ecosystem of external packages that everyone else uses. In this case, the author is working on AI & computer vision, for which everyone else uses Python. Python could be a much worse language than it is and using Python would still be the right choice in this scenario.
It's pretty much the same for AI, except that there is an increasing trend in AI of it being used by people that do not have the skills to do the productionization.
This is due to lots of boilerplate, complex types, usage of abstract base classes, adding code for testing purposes into the production codebase due to disregarding language features such as mocking, etc...
The development time and bugs in a program are directly proportional to the total number of lines written.
You write 3x the number of lines of code using a verbouse code style then you have 3x the number of bugs. Static type checking only catches around 5% of bugs. It's not a significant debugging tool.
If instead of writing static types and all the involed boilerplate required to make it work, you instead invested that type in unit tests and proper qa, you will always come out ahead.
C, C++ are the main ones.
Understood, no need to argue then, I don't think any amount of proof would change your mind...
You know the rule, 99% of everything is crud.
Rewriting it in C++, leveraging the platform-specific APIs for disk I/O (sync_file_range on Linux, not even wrapped by a Python module) would yield not only much better performance, but also much higher reliability.
As it is this daemon is a recipe for page thrashing. Not that I would expect a Python dev to actually know how a kernel works.
You ship C code which is extensively tested by Python code.
Python is simple to use, got good C interop and the performance of your test frameworks hardly matters.
It takes a lot of effort to make a Python program not break on some inputs, so it's not really fire and forget like it is with C++. It's possible but it requires many more iterations.
Seriously questionable assertion to my eyes. Maybe I just haven't used C++ in way too long to appreciate that it's true. I have heard lots of people say that modern C++ is really great.
Realistically I think it depends what you are doing. For some code type hinting is useful. Some code it is not.
Yes and I'm going to be honest, my first worry when type hints came around is that the language would be inundated by the java drones where they would enforce this 100% of the time.
Instead it seems people are mostly using it where it makes sense (APIs, etc)
Type hints are a great asset. You don't have to use it everywhere. And it should remain that way
Duck typing implies that "Should this work?" has one true answer: "Did it work?" I am at work to work, not to play guess-and-check with upstream libraries.
Using Duck typing in a scripting language is the correct choice.
"Did it work?" is a point-in-time observation. It is always situational. To find out, I have to construct esoteric objects with unobservable internal state and hope it is the state that I actually care about.
"Should it work?" has an answer of infinite duration. I can recall what I learned years later without needing to re-run some experiment.
Django-Ninja use them to do dependency injection and generate schemas for your API (using pydantic). autodoc use them to generate the documentation of your function. etc...
It does not replace duck typing, proof here: https://peps.python.org/pep-0544/