Almost none of the computation in a Python machine-learning program happens in Python. Call a matrix multiplication and the interpreter spends a few microseconds arranging arguments before handing control to compiled code, which does the arithmetic over a contiguous block of memory, frequently on a GPU, and returns. The language's celebrated slowness applies to the arranging, not to the arithmetic, and the arranging happens once per operation rather than once per number. That boundary is the entire trick, and it is why the argument about Python being slow keeps missing what the language is being used for. It is not performing the work. It is describing the work to something else, and it is unusually good at that because its C extension interface is old, stable and widely understood, so a library author working in another language can expose a usable surface without adopting Python's runtime for anything that matters.
The other half of the explanation is standardisation. The NumPy array became a shared currency: pandas, SciPy, scikit-learn, the plotting libraries and later the deep-learning frameworks all accept and return the same object, so tools written by strangers who never coordinated compose without conversion layers between them. That is a rarer achievement than it sounds, and the alternatives lost to it for individual reasons rather than one general one. R is superb at statistics and never became the language anyone would also write the serving layer in. MATLAB was licensed per seat, which excluded the students and open-source researchers who went on to write the field's next decade of code. Julia addressed the underlying problem more elegantly and arrived after the ecosystem had already set. The clearest evidence sits in the history of one framework: Torch was respected and written in Lua, the same research lineage rebuilt it with a Python front end as PyTorch, and the audience followed the front end rather than the ideas, which had barely changed.
What to learn, and where the edges are
For a beginner the usual advice is correct, for a slightly different reason than the one usually given. Learn Python first not because the syntax is gentle, although it is, but because it leaves you one import away from nearly every tool you will subsequently need: pandas and Polars for tables, scikit-learn for classical models, PyTorch for neural networks, Matplotlib when a chart is for your own eyes. The gentle syntax earns its reputation mainly by keeping the difficulty inside the problem instead of inside the ceremony. Then learn where the edges are, before an interviewer finds them for you. Loops written in pure Python over large collections are slow enough to matter, and the remedy is to push the loop down into a library call rather than to optimise the loop itself. The global interpreter lock prevents threads from executing Python bytecode simultaneously, which is largely irrelevant to numerical work because the compiled libraries release it while they compute, and recent versions have shipped an experimental build without that lock at all. Packaging remains the least pleasant part of the language by a wide margin, so pick one modern environment manager and use it for everything. None of that changes the recommendation. It means you will know which complaints about Python are real and which are only recited.