3 ms·

"C-extension issues" are not something you can just gloss over. They're a huge chunk of python usage. Users won't rally around that. And Hpy is dead. If CPython

"C-extension issues" are not something you can just gloss over. They're a huge chunk of python usage. Users won't rally around that. And Hpy is dead. If CPython embraced PuPy, worked with it to smooth those issues then maybe things would be different.

pjmlp 15d ago
To the point that in Python culture those C extensions are seen as Python libraries, not bindings.
theandrewbailey 14d ago
Maybe PyPy needs a Steve Jobs-like figure to write a "no C extension" manifesto, declaring that all Python apps must be 100% Python.
- bastawhiz 14d ago
  Is there a single example of a language+runtime where this approach has ever been successful
  - pjmlp 14d ago
    Well, see popularity of CGO among Go devs, or JNI among Java devs, or the ongoing work to make all the learnings from System C# (from Midori) available in regular C#, while C++/CLI is slowly left in maintenance mode (last updated for partial C++20 support, and not part of FOSS .NET)
    - bastawhiz 14d ago
      All of those are for non native code to call code in those languages. Nobody is saying "all Go code must never invoke native code". That would be wild and to my knowledge, there's no major language that forces such a constraint.
      - pjmlp 14d ago
        All the languages I mentioned compile to native code.
        bastawhiz 13d ago
        I can't tell if you're being willfully ignorant or not. The comment I was replying to was proposing banning C extensions: invoking native binaries that are not written in the host language and compiled in (at build or runtime). What you're describing has nothing to do with that.
        pjmlp 13d ago
        Why would a Go binary (to keep the examples short), compiled to native code, with a compiler toolchain that includes support for Assembly if necessary, and a syscall package as well, have to depend on C extensions? CGO only exists as a matter of convenience.
  - zbentley 13d ago
    I do think Go and Java are strong examples of this. Those languages have native code support, but it’s clunky to use and, more importantly, very rare. If you removed JNA/JNI/CGo, plenty of people would complain…but the vast majority of uses of those languages would still work, unaltered, because most common tasks on the JVM and Go runtime don’t require external native deps.

pjmlp 15d ago

To the point that in Python culture those C extensions are seen as Python libraries, not bindings.

theandrewbailey 14d ago

Maybe PyPy needs a Steve Jobs-like figure to write a "no C extension" manifesto, declaring that all Python apps must be 100% Python.

bastawhiz 14d ago
Is there a single example of a language+runtime where this approach has ever been successful
- pjmlp 14d ago
  Well, see popularity of CGO among Go devs, or JNI among Java devs, or the ongoing work to make all the learnings from System C# (from Midori) available in regular C#, while C++/CLI is slowly left in maintenance mode (last updated for partial C++20 support, and not part of FOSS .NET)
  - bastawhiz 14d ago
    All of those are for non native code to call code in those languages. Nobody is saying "all Go code must never invoke native code". That would be wild and to my knowledge, there's no major language that forces such a constraint.
    - pjmlp 14d ago
      All the languages I mentioned compile to native code.
      - bastawhiz 13d ago
        I can't tell if you're being willfully ignorant or not. The comment I was replying to was proposing banning C extensions: invoking native binaries that are not written in the host language and compiled in (at build or runtime). What you're describing has nothing to do with that.
        pjmlp 13d ago
        Why would a Go binary (to keep the examples short), compiled to native code, with a compiler toolchain that includes support for Assembly if necessary, and a syscall package as well, have to depend on C extensions? CGO only exists as a matter of convenience.
- zbentley 13d ago
  I do think Go and Java are strong examples of this. Those languages have native code support, but it’s clunky to use and, more importantly, very rare. If you removed JNA/JNI/CGo, plenty of people would complain…but the vast majority of uses of those languages would still work, unaltered, because most common tasks on the JVM and Go runtime don’t require external native deps.