2 ms·

I would suggest the C API is just as much a part of Python as the standard library, and numpy (and swig) predates Unladen Swallow (see e.g. https://stackoverflo

I would suggest the C API is just as much a part of Python as the standard library, and numpy (and swig) predates Unladen Swallow (see e.g. https://stackoverflow.com/questions/2328267/unladen-swallow-with-numpy-scipy https://stackoverflow.com/questions/2328267/unladen-swallow-... for people trying to get them to work together). I don't think it's surprising that micropython/circuitpython have had more success, in many ways they are a port to an environment where the existing libraries wouldn't be used, so they can at some level build their own ecosystem.

mananaysiempre 2y ago
> numpy (and swig) predates Unladen Swallow Sure, but that doesn’t contradict what I said. Numpy is surprisingly old, but in 2010 (my impression was that) supporting it was in no way table stakes for an implementation of Python. Hell, Jython was still occasionally taken seriously then, and Microsoft still pretended they cared about IronPython. > I would suggest the C API is just as much a part of Python as the standard library As things stand, yes, no question. The problem is, it was never designed that way. In particular, it cannot (or at least is not designed to) support any other memory management strategy but CPython’s, thus efforts like HPy[1]. For example, while the language docs admonish you not to depend on __del__ running at any particular moment, if we consider the Python/C API a part of the language, then the language has to behave as though it uses naïve reference counting and occasionally runs a cycle collector. And that’s the easy part—think about how deeply the GIL is rooted there. That is not good design for something that’s part of the language, as it effectively is. It was never intended to be and never received commensurate amounts of care. It just turned out that way—and ain’t that a sad thing to admit. [1] http://hpyproject.org/ http://hpyproject.org/
- aragilar 2y ago
  I think even back in 2010 (which ironically when I was getting into scientific Python to replace MatLab scripts for labs), numpy was table stakes for any implementation that wanted to be used in scientific Python communities (note that these started in the 90s). Whether the scientific Python communities were big enough then to prevent Unladen Swallow succeeding I don't know, but it would be interesting to compare the Python C API, HPy, and the C APIs (if any) of Perl, Ruby and Tcl (given PDL existed but seemingly failed to be adopted, and Tcl was widely used in science software but also seems to have died out), and see if there was anything about Python's one that caused it to be adopted so widely (my feeling is Java's lack of scripting and baroqueness ruled it out no matter the state of JNI).

mananaysiempre 2y ago

> numpy (and swig) predates Unladen Swallow Sure, but that doesn’t contradict what I said. Numpy is surprisingly old, but in 2010 (my impression was that) supporting it was in no way table stakes for an implementation of Python. Hell, Jython was still occasionally taken seriously then, and Microsoft still pretended they cared about IronPython. > I would suggest the C API is just as much a part of Python as the standard library As things stand, yes, no question. The problem is, it was never designed that way. In particular, it cannot (or at least is not designed to) support any other memory management strategy but CPython’s, thus efforts like HPy[1]. For example, while the language docs admonish you not to depend on __del__ running at any particular moment, if we consider the Python/C API a part of the language, then the language has to behave as though it uses naïve reference counting and occasionally runs a cycle collector. And that’s the easy part—think about how deeply the GIL is rooted there. That is not good design for something that’s part of the language, as it effectively is. It was never intended to be and never received commensurate amounts of care. It just turned out that way—and ain’t that a sad thing to admit. [1] http://hpyproject.org/ http://hpyproject.org/

aragilar 2y ago
I think even back in 2010 (which ironically when I was getting into scientific Python to replace MatLab scripts for labs), numpy was table stakes for any implementation that wanted to be used in scientific Python communities (note that these started in the 90s). Whether the scientific Python communities were big enough then to prevent Unladen Swallow succeeding I don't know, but it would be interesting to compare the Python C API, HPy, and the C APIs (if any) of Perl, Ruby and Tcl (given PDL existed but seemingly failed to be adopted, and Tcl was widely used in science software but also seems to have died out), and see if there was anything about Python's one that caused it to be adopted so widely (my feeling is Java's lack of scripting and baroqueness ruled it out no matter the state of JNI).