5 ms·

I strongly disagree with the author's assertions that the need for better C API support is strictly a need for integrating with "legacy applications". The fact

I strongly disagree with the author's assertions that the need for better C API support is strictly a need for integrating with "legacy applications". The fact of the matter is that a vast array of systems-level software and high-performance software is only available via a C API interface. New or old, that's still true today. I've used ctypes and I've used cffi; I'm glad they exist, but authors of popular packages often don't have the luxury of supporting both of them and the CPython API. If by legacy, they're attempting to paint the CPython API as the legacy one, I also find that a misleading argument at best. PyPy is not yet the official future of Python, and attempting to paint themselves as the successor without any clear indicator of support for that future from the Python leadership seems odd. I'm all for them getting financial support they need to do the work, but attempting to justify that work by claiming only "legacy" applications need it seems uninformed at best.

frozenport 11y ago
C APIs also offer significantly easier distribution, as you don't need to worry about things like name mangling or support for other languages. Much better than alternatives like COM.
DasIch 11y ago
The author only claims that better CPython C API support is needed for legacy applications. Of course there are a vast number of applications that have C API themselves that one might want to accesses. You can interact with those through cffi in a way that's simple and performant already.
- bpicolo 11y ago
  The bigger issue is the larger number of packages using the C Api, not the applications themselves
- stuaxo 11y ago
  GUI apps is an area that comes to mind. Gtk3 uses the C API, although you can try and use PGI it is not fully ready. In fact, lots of old graphics and sound APIs are the same... basically anything that is not hooked up to the web.
  - deleted 11y ago
    [deleted]
Animats 11y ago
"PyPy is not yet the official future of Python." We're past that point. PyPy is the future. CPython is the past. The PyPy team succeeded in making an optimizing compiler for a language that fought them every step of the way with gratuitous hidden dynamism. That's a considerable achievement. It extends the life of Python by making it competitive on speed. Go exists mostly because Python was too slow. Google used to use Python quite a bit internally, but their effort to speed it up, Unladen Swallow, was a disaster. That provided some of the motivation for Go.
- mangeletti 11y ago
  I upvoted you on the sheer idea that performance is paramount to the future of Python. I think Python needs to be 5x faster and use 1/5th the memory for the same tasks, in order to remain relevant years from now. But, I still think PyPy has a long way to go.
- Demiurge 11y ago
  > We're past that point. PyPy is the future. CPython is the past. CPython is the past and is the present, and the future you can't predict. However, if you try to extrapolate, you should perhaps consider as much historical context as possible. For instance, why is Python what it is? Is it speed? I think it is the accessibility of language syntax, design and features. CPython is the base of this language evolution, and PyPy is improving just speed. So I would extrapolate CPython to always be more popular. Go exists because someone at Google wanted to make better C and C++, a statically typed language. It doesn't have much to do with Python. Google always preferred C++ and Java to python because of static typing, not just because of speed. Overall, I think it's a mistake to fixate so much on speed of execution, when often times speed of development is considered more important. This niche is never going away, despite of how hard some people hammer square pegs in round holes.
  - BuckRogers 11y ago
    >Overall, I think it's a mistake to fixate so much on speed of execution, when often times speed of development is considered more important. This niche is never going away, despite of how hard some people hammer square pegs in round holes. That's the point to PyPy. You get fast speed of development and fast CPU performance. Best of every world. That's why we use it and not CPython. It's already bigger than you think.
fijal 11y ago
If you can change the extension, then going for cffi seems like a no-brainer. It works on cpython, it's easier to use, safer etc. Usually the problem is if the application/library is too big/too cumbersome. Then I think it's fair to call it legacy
lucian1900 11y ago
cffi works fine on CPython and it's also quite fast. It ends up with pretty much the same result.

frozenport 11y ago

C APIs also offer significantly easier distribution, as you don't need to worry about things like name mangling or support for other languages. Much better than alternatives like COM.

DasIch 11y ago

The author only claims that better CPython C API support is needed for legacy applications. Of course there are a vast number of applications that have C API themselves that one might want to accesses. You can interact with those through cffi in a way that's simple and performant already.

bpicolo 11y ago
The bigger issue is the larger number of packages using the C Api, not the applications themselves
stuaxo 11y ago
GUI apps is an area that comes to mind. Gtk3 uses the C API, although you can try and use PGI it is not fully ready. In fact, lots of old graphics and sound APIs are the same... basically anything that is not hooked up to the web.
- deleted 11y ago
  [deleted]

Animats 11y ago

"PyPy is not yet the official future of Python." We're past that point. PyPy is the future. CPython is the past. The PyPy team succeeded in making an optimizing compiler for a language that fought them every step of the way with gratuitous hidden dynamism. That's a considerable achievement. It extends the life of Python by making it competitive on speed. Go exists mostly because Python was too slow. Google used to use Python quite a bit internally, but their effort to speed it up, Unladen Swallow, was a disaster. That provided some of the motivation for Go.

mangeletti 11y ago
I upvoted you on the sheer idea that performance is paramount to the future of Python. I think Python needs to be 5x faster and use 1/5th the memory for the same tasks, in order to remain relevant years from now. But, I still think PyPy has a long way to go.
Demiurge 11y ago
> We're past that point. PyPy is the future. CPython is the past. CPython is the past and is the present, and the future you can't predict. However, if you try to extrapolate, you should perhaps consider as much historical context as possible. For instance, why is Python what it is? Is it speed? I think it is the accessibility of language syntax, design and features. CPython is the base of this language evolution, and PyPy is improving just speed. So I would extrapolate CPython to always be more popular. Go exists because someone at Google wanted to make better C and C++, a statically typed language. It doesn't have much to do with Python. Google always preferred C++ and Java to python because of static typing, not just because of speed. Overall, I think it's a mistake to fixate so much on speed of execution, when often times speed of development is considered more important. This niche is never going away, despite of how hard some people hammer square pegs in round holes.
- BuckRogers 11y ago
  >Overall, I think it's a mistake to fixate so much on speed of execution, when often times speed of development is considered more important. This niche is never going away, despite of how hard some people hammer square pegs in round holes. That's the point to PyPy. You get fast speed of development and fast CPU performance. Best of every world. That's why we use it and not CPython. It's already bigger than you think.

fijal 11y ago

If you can change the extension, then going for cffi seems like a no-brainer. It works on cpython, it's easier to use, safer etc. Usually the problem is if the application/library is too big/too cumbersome. Then I think it's fair to call it legacy

lucian1900 11y ago

cffi works fine on CPython and it's also quite fast. It ends up with pretty much the same result.