[8589934591]

Typically, the selection of a programming language is predetermined in brownfield projects, leaving little room for choosing the "ideal" programming language for migration unless it is absolutely necessary (go can be a suitable option for migrations).

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.

[v21]

> Typically, the selection of a programming language is predetermined in brownfield projects, leaving little room for choosing the "ideal" programming language for migration unless it is absolutely necessary (go can be a suitable option for migrations).

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.

[mgaunard]

In computer vision, you use Python for prototyping and research. It of course gets rewritten if it's to be actually used, think for example of the guidance system in a car, plane, or weapon.

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.

[kobzol]

I agree that in most cases it should be rewritten for production, but in my experience that quite often doesn't happen, and AI stays in Python even for production usages.

[ReflectedImage]

Using static typing in Python will generally speaking significantly increase the number of bugs in the codebase.

[8589934591]

Could you elaborate your statement? How? My experience says otherwise. I am interested to know your viewpoint and experience.

[ReflectedImage]

Of course, statically typed code is usually around 3 times the number of lines of code as it's dynamically typed equivalent.

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.

[mgaunard]

I'm pretty sure any serious company uses C++ for the code that matters, and Python for orchestration (assuming no high scalability requirements), GUI, offline data analysis and calibration, etc.

[rglullis]

Your idea of "serious company" is outdated by at least 20 years.