My package has both Python code ("module") and a C extension ("_module"). The C extension code is under src/ following a long Unix tradition.
With the Python-module(s)-under-"src/" option, where do people usually place their C extension code?
It's clear that I could use any name, like "pysrc", and not just "src/" for the Python code. What I'm asking about is if there is a growing consensus about how to organize a package with both Python and C modules.
Checking my local copies of different packages containing both C and Python:
matplotlib: src/ contains C code while lib/ contains Python
cffi: c/ contains C code, there is no lib/
numpy: contains C code in many places, like numpy/core/src/ ; no lib/
pyzmq: contains C code mostly under zmq/core/ ; no lib/
python-cdb: contains C code under src/ ; no lib/
Checking a few other packages:
pycuda: contains C code under src/ ; no lib/
Pillow: contains C code under src/ ; no lib/
tornado: the one C file is under tornado/ ; no lib/ or src/
Caffe: C++ code under src/ ; no lib/
That is, I haven't found any packages which put C extension code under lib/ .
Ah, my mistake. I know that CPython and matplotlib both have a lib/ directory, but you're right that that's where they keep the Python code and they keep the C code in Modules/ and src/, respectively.
Also I may have confused this with the src/ layout in the past and put my own C extensions into lib/. Thanks for the survey, I think I've been harboring this misconception for a while now.
With the Python-module(s)-under-"src/" option, where do people usually place their C extension code?
It's clear that I could use any name, like "pysrc", and not just "src/" for the Python code. What I'm asking about is if there is a growing consensus about how to organize a package with both Python and C modules.