Diseño de directorio para un proyecto de Python con módulos de extensión C

Question

Tenemos numerosos proyectos en nuestra organización que están mezclados Python/C. Actualmente estamos tratando de estandarizar el diseño de un directorio para nuestros proyectos y estamos tratando de encontrar un esquema conveniente. Un punto de discordia es dónde poner los módulos de extensión C en el árbol.

Estamos lanzando en torno a un par de opciones (relativo a la raíz del proyecto):

./src/package/subpackage/module.c 

o junto a los módulos de Python en el árbol de paquetes:

./package/subpackage/module.c 

o en un directorio en src el subpaquete:

./package/subpackage/src/module.c 

Una razón para mantenerlos fuera del paquete director Esto podría ser porque generará desorden, especialmente si hay otros archivos .c y .h que no son en sí mismos módulos pero que aún necesitan ser compilados. También en el esquema "integrado", ¿qué haces con los encabezados y archivos que utilizan más de un módulo? Póngalos en un directorio común de alto nivel?

Me interesaría saber qué están usando otras personas, o si existen algunas mejores prácticas establecidas para esto.

Answer 1

creo que el diseño de la biblioteca estándar de Python es un ejemplo razonable: bajo trunk, que es básicamente la raíz del repositorio SVN (neto de ramas & c), el directorio Modules tiene una gran cantidad de .c y .h archivos, el directorio Lib muchos archivos .py.

En mis propios proyectos, tiendo a dividir las fuentes de manera similar (y en realidad si tengo Cython o Pyrex, o SWIG, tiendo a tener otros directorios aún para la subdivisión), aunque con diferentes nombres de directorio (confieso que no tengo una regla consistente para los nombres del directorio en sí, ni he oído hablar de buenas pautas para tales nombres).