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.

▲

pjmlp 3 months ago | parent [-]

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.

▲

woodruffw 3 months ago | parent [-]

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.)

▲

pjmlp 3 months ago | parent [-]

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.

	▲	woodruffw 3 months ago \| parent [-]
		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.