4 ms·

As a noob who recently moved away from the Python land, it is mind-blowing to me that the shim needed to communicate with a foreign library (or even, bare metal

by barosl 12y ago

As a noob who recently moved away from the Python land, it is mind-blowing to me that the shim needed to communicate with a foreign library (or even, bare metal) is that simple. When I first learned Python years ago, I was told that I can specialize some parts of my Python program using C code to speed up the entire application. However, I've never tried that. Maybe it seemed too complicated to me? I don't know, but it just haven't made my mind go.

icebraining 12y ago
It's not really very hard if you know the basics of C, the only weird part is having to deal with a bunch of Py* functions and types to interface with Python's. The official docs are nice: https://docs.python.org/2/extending/extending.html https://docs.python.org/2/extending/extending.html
- masklinn 12y ago
  If all you want is to call into C code, without needing to really expose that code as Python objects, CFFI[0] is probably a simpler path. [0] https://cffi.readthedocs.org/en/release-0.8/ https://cffi.readthedocs.org/en/release-0.8/
- shadowmint 12y ago
  I dont know if you've ever tried this using python3, but the Unicode internals make it significantly more complex.
  - MichaelGG 12y ago
    Wow I just read up on that. Python 3 is from the late '00s but it still uses fixed 16-bit characters? That's just silly. Pay double the price for most strings, and still get Unicode support wrong. And then the newer versions "fix" this by allowing 32-bit characters? And even newer versions can do a different encoding per string? I know people like O(1) indexing into strings, but I'm unconvinced it's so useful to totally fuck up your string implementation. Java, Windows and .Net have the excuse of being thought up before Unicode was over 16-bits so it's slightly excusable (but still a bad tradeoff for many, many, applications, probably the majority of server apps).
fit2rule 12y ago
Scale back a bit, and have a look at Lua! If you've got C chops, you can learn to put Lua anywhere .. its another way to look at the same problem, albeit in a similarly compact fashion...

by barosl 12y ago

icebraining 12y ago

It's not really very hard if you know the basics of C, the only weird part is having to deal with a bunch of Py* functions and types to interface with Python's. The official docs are nice: https://docs.python.org/2/extending/extending.html https://docs.python.org/2/extending/extending.html

masklinn 12y ago
If all you want is to call into C code, without needing to really expose that code as Python objects, CFFI[0] is probably a simpler path. [0] https://cffi.readthedocs.org/en/release-0.8/ https://cffi.readthedocs.org/en/release-0.8/
shadowmint 12y ago
I dont know if you've ever tried this using python3, but the Unicode internals make it significantly more complex.
- MichaelGG 12y ago
  Wow I just read up on that. Python 3 is from the late '00s but it still uses fixed 16-bit characters? That's just silly. Pay double the price for most strings, and still get Unicode support wrong. And then the newer versions "fix" this by allowing 32-bit characters? And even newer versions can do a different encoding per string? I know people like O(1) indexing into strings, but I'm unconvinced it's so useful to totally fuck up your string implementation. Java, Windows and .Net have the excuse of being thought up before Unicode was over 16-bits so it's slightly excusable (but still a bad tradeoff for many, many, applications, probably the majority of server apps).

fit2rule 12y ago

Scale back a bit, and have a look at Lua! If you've got C chops, you can learn to put Lua anywhere .. its another way to look at the same problem, albeit in a similarly compact fashion...