1. 19
  1.  

  2. 2

    Every time I’ve wanted to extend python with more than a function or two, swig has been the right answer for me. But I’ve always had a C or C++ codebase that I wanted to use in the extension.

    For C or C++, it eliminates a lot of the verbose boilerplate the article complains about.

    1. 2

      Ah yes, I’ll mention that; it also does other languages, I think? I would still expect pybind11 to be a lot nicer for C++ though, based on previous experience with boost::python.

      1. 1

        It does. We’ve used it before to generate interfaces for the same library for C#, python and java. Last time I tried boost::python it was good but you kind of had to be all-in on boost::build, and (not python-related) we weren’t. If I had to do it again and only cared about targeting python, I’d definitely look at it again now that there’s a Cmake build system for boost.

        1. 2

          Ah, so, pybind11 is like boost::python without going all in on Boost, is my understanding.

          Think of this library as a tiny self-contained version of Boost.Python with everything stripped away that isn’t relevant for binding generation.

          1. 1

            Reading those docs, pybind11 looks really nice. I think if I had a library where my swig interface file started to get non-trivial, if I knew I just needed python I’d try pybind11 before writing a large swig interface.

            (One of the cool things about swig is that you often don’t have to do more than write a couple marshal functions, then just mark up your C or C++ headers and it works without much fuss. Occasionally, that doesn’t age well and you wind up writing a lot of swig interface.)

      2. 2

        For anyone wondering about production uses of swig, Google uses it to generate Python bindings for internal libraries.

        1. 1

          SWIG left a bad taste in my mouth in 2004. I was using some Python bindings for a few fairly obscure Windows APIs, specifically Microsoft Active Accessibility, low-level keyboard hooks, and the Microsoft Speech API. On the one hand, I’m indebted to the developers of these bindings for helping me get started writing a Windows screen reader when I was still pretty new to Windows programming. On the other hand, my dim recollection is that the Active Accessibility bindings in particular were crash-prone. I dug into that code at the time, but I don’t really remember what I found. It’s possible that those bindings were stretching SWIG beyond what it could really handle; after all, these bindings were for a COM-based API. But in any case, after that, I wanted to stay away from SWIG as much as I could.

        2. 1

          One example is cryptography, by moving to rust implementation, the build time is now forever and takes gigabytes of disk.

          1. 7

            Like basically any package that involves compiled extensions, they provide pre-built binary .whl packages, so pip install cryptography should not involve having to compile anything on the target machine. Any extra time/space required by the compilation is thus incurred only by the people who build the packages.

            1. 2

              Unfortunately there are no ARM packages, so having to install anything that uses cryptography on a Raspberry Pi takes… well, I don’t know how long it takes, I only started it two months ago.

              1. 3

                There are aarch64 packages on PyPI: https://pypi.org/project/cryptography/#files

                One thing to try is upgrading pip before you install cryptography, old versions of pip won’t know about manylinux2014 for example.

                1. 1

                  Ahh, I will try that next time, thank you! Just have been that.

              2. 1

                That’s exactly what I did to upgrade the py3-cryptography in alpine.

                1. 1

                  For quite some time all Python .whl packages with compiled extensions were compiled with glibc (due to being the easiest way to define a lowest-common-denominator “Linux” compilation target), which meant they were not compatible with musl-based distros. There is now a platform tag on PyPI for packages built against musl, and the cryptography project now provides .whl pre-compiled packages using musl (as well as ones for glibc).

                  1. 1

                    That would be nice, however that also requires package maintainers to rebuild the whls. That feature is only added in September for cibw, so it might take a while to get fully adopted.