One could perhaps draw a distinction between languages that were designed from the ground up as multiparadigm, such as OCaml, and languages that originally targeted one paradigm and then became multiparadigm by katamari-ing up a bunch of extra features, as Python did.

FWIW, I also don't know that Python officially conceives of itself as multiparadigm so much as as a procedural language with classes. Kids these days forget that higher-order programming has a long history in procedural programming, too. ALGOL was doing it in the 1960s, after lisp but a good decade before Backus published Can Programming Be Liberated from the von Neumann Style?.

For what it's worth, despite the O in OCaml, in practice the object layer isn't used that often. However, that's because the ML module system serves many of the same use cases that objects and classes do in other languages. People do use objects in OCaml occasionally if they need the dynamic dispatch.

I'd say that OCaml blends imperative and functional programming cohesively and fairly equally, though.

The python leadership commitee has always been explicitly anti "functional programming". They only allow a few functional things that serve Python's overall goal of making basic problems simple to solve.

The problem lies more on the programmer than the language.

Which problem?

Learning programming and architecture best practices.

How programming paradigms can be lift over to the level of "algorithms + data structures", regardless of the language.