Pure Python was a huge selling point back when using a compiled library involved downloading and running random .exe files from someone's personal page on a university website. It is much less of a selling point now that we have binary wheels and uv/Poetry/etc. that create cross-platform lock files.

I feel nostalgic seeing (a mirror of) that download page again, but that era was such a pain.

Mirror: http://qiniucdn.star-lai.cn/portal/2016/09/05/tu3p2vd4znn

I always thought the selling point of Pure Python was that you might be running on some esoteric implementation of python, or hardware that the library maintainer didn't include binaries for.

I mean, I am glad wheels exist, they make things a lot easier for a lot of people. I just believed in the dream of targeting the language for maximum compatibility and hoping a better implementation would eventually run it faster.

Indeed. I was an early adopter of Google's App Engine using Python and at that time Pure Python is a must.

I rather find tragic that contrary to other dynamic languages, Python seems to fall under the curse of rewriting bindings into C and C++, or nowadays more fashionable Rust.

And yes, Smalltalk, Self and various Lisp variants are just as dynamic.

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.

I certainly don't miss needing to install additional system libraries in addition to my pip install.

In what way does having to compile a Rust library prevent this?

IME, and I may be off base, the new generation of Rust/Go binaries have a more "batteries-included" philosophy, i.e. developers don't assume that they can piggyback off existing user system libraries, which generally makes it a nicer install UX.

It will fail to compile as well if they depend on any system library or OS specific feature not present on your system.

Yeah, I heard about this new one taken from browsers.

It is supposed to fix everything that previous ones never achieved.