DOC: Inaccurate caveat regarding ctypes

[memeplex]

The "Using python as glue document" states that

There is no standard way in Python distutils to create a standard shared library (an extension module is a “special” shared library Python understands) in a cross-platform manner. Thus, a big disadvantage of ctypes at the time of writing this book is that it is difficult to distribute in a cross-platform manner a Python extension that uses ctypes and includes your own code

But, in fact, build_ext could be used out of the box in most platforms and it's trivial to make it work in Windows. See my answer here. I think something like this recipe could be added to the document in place of the inaccurate and demotivating "big disadvantage" warning.

[rkern]

Is there a published package that uses this technique?

[memeplex]

I don't know, I've been using it for a time without problems. There is nothing really special in extension modules besides file naming, initialization and linking against libpython, AFAIK. Most of the built_ext machinery still applies.

[memeplex]

Besides I don't think there are many published packages using ctypes for custom modules, using this technique or not. Most use cython, swig or extension modules.

[mattip]

The document could use an overhaul,

• updating the section on ctypes with an example
• adding examples from OpenCV, the deep-learning world, and GnuRadio
• adding memoryview and cffi as additional ways to interchange buffers

[rgommers]

adding examples from OpenCV, the deep-learning world, and GnuRadio

I'd prefer not to do this part. That belongs in the docs of those packages or a general tutorial, not the numpy docs - just more maintenance for us.

[liang3zy22]

I am working to solve this issue. I have one question. Currently setuptools is mainly used and distutils is legacy. Should the Cython part be updated to setuptools version?

[mattip]

I am not sure that document belongs in NumPy anymore. It is not really NumPy-specific, and many other tools exist that are not mentioned there: PyO3, nanobind, CFFI. CTypes is largely recognized to be slow and not maintained. Maybe we should just put a note at the top "This was written in 2008 as part of the original Guide to NumPy book by Travis E. Oliphant and may be out of date"

[liang3zy22]

That's right. I will create a PR to add the note.