This is fine as long as you can convince management to spend the money to rewrite your software. That's usually a hard sell though. In my experience this plan usually ends up with a python monstrosity that everyone hates but is forced to deal with forever.

I'm speaking in terms of the reality of what is effective in development. Not in terms of what management at particular companies will approve.

Type hints and dataclasses are a game-changer for Python. Much easier to reason about programs that use them.

> Type hints and dataclasses are a game-changer for Python. Much easier to reason about programs that use them.

Type hints made large python codebase switch from "Any change will blow up to my face" to "I can touch it carefully with protection gloves".

Through, it is still pretty easy to fool mypy and very far of the compile time guarantees that provide most static typed AOT compiled language.

And unfortunately, it also does not bring any advantage in term of performance.

> Type hints...

At that point it makes more sense to use a statically typed language.

You just have to write a tiny part that uses a lot of CPU in C++/asm or anything else.

Much of code's performance isn't really reflected on to the scalability since mostly a tiny part of code is really ran a lot of time, and the other parts are just glues or management stuff or rarely used(not used in scale) features.

It depends. You aren't going to make a very fast modern codec encoder or decoder using Python. The hotspot ends up being the vast majority of the process. That management/glue layer becomes very thin, amounting only to feeding in the bitstream and reading back the raw video frames.