Why is it tragic? It's more or less idiomatic in Python to put the hot or performance-sensitive paths of a package in native code; Rust has arguably made that into a much safer practice.

Because it forces mastering two languages, or depending on third party developers for anything that matters beyond basic OS scripting tasks.

It became idiomatic as there was no other alternative.

You don’t have to master Rust to use this, the same way you don’t have to master C to use all of the critical extensions written in it.

(Besides, no language has this regardless of native extensions: a huge part of Python’s success comes from the fact that there isn’t a perfect graph of competencies in the community, and instead that community members provide high quality abstractions over their respective competencies.)

Assuming someone else fixes the issues that might come up.

One of the pain points from Python is exactly native libraries and getting them compiled.

Sure, but that’s the general maintenance risk. I don’t think native code changes that dynamic, particularly in ecosystems where it’s the norm. And doubly so for cryptographic code, where native is the norm for performance and certification reasons.

It’s my impression as a maintainer of many projects that native compilation hasn’t been a driving issue in Python packaging for a while now. Most users download wheels and sidestep the entire problem. Whether or not they should trust random binaries from the internet is of course a bigger question.

It's part of the original selling points of python, so it's not surprising that we've never stopped doing it.

As someone that has been using Python since version 1.6 that was certainly not one of the original selling points.

Rather being a better Perl for UNIX scripts and Zope CMS, there was no other reason to use Python in 2000.