missing - Convención de nomenclatura del módulo de objeto compartido de Python

python enhancement proposal no 8 pep8

Question

He escrito un módulo de Python en C ++ y lo construí como una biblioteca de objetos compartidos y funcionó bien. Pero mientras averiguaba todo eso, noté (a través de strace) que Python busca algunas variaciones diferentes a las que se llama import . En particular, cuando digo import foo , Python busca, en orden:

• foo (un directorio)
• foo.so
• foomodule.so
• foo.py
• foo.pyc

Todo esto fue bastante comprensible, excepto para foomodule.so. ¿Por qué Python busca todo como name.so y namemodule.so? ¿Es algún artefacto histórico? Busqué bastante y no encontré ninguna explicación, y me pregunto si debería nombrar mi módulo foomodule.so en lugar de foo.so. Mi sistema parece tener algunos módulos Python existentes después de cada convención, por lo que no puedo evitar preguntarme si los diferentes nombres implican algo.

Answer 1

En realidad, esto depende de la plataforma, Python tiene diferentes sufijos que intenta dependiendo del sistema operativo. Aquí está la inicialización de la tabla de sufijos en import.c :

#ifdef HAVE_DYNAMIC_LOADING
memcpy(filetab, _PyImport_DynLoadFiletab,
countD * sizeof(struct filedescr));
#endif
memcpy(filetab + countD, _PyImport_StandardFiletab,
countS * sizeof(struct filedescr));
filetab[countD + countS].suffix = NULL;
_PyImport_Filetab = filetab;

Así que se une a dos listas, _PyImport_DynLoadFiletab y _PyImport_StandardFiletab . El último es el más fácil, se define como [".py", ".pyw", ".pyc"] en el mismo archivo (la segunda entrada solo está presente en Windows). _PyImport_DynLoadFiletab se define en varios dynload_<platform>.c . En sistemas basados ​​en Unix su valor es [".so", "module.so"] , para CygWin define [".dll", "module.dll"] mientras que para OS / 2 es [".pyd", ".dll"] y para Windows es simplemente [".pyd"] .

Revisé el historial del código fuente y finalmente llegué a este cambio de 1999 que aparentemente agregó "module.so" como posible sufijo: http://hg.python.org/cpython-fullhistory/diff/8efa37a770c6/Python/importdl.c . Por lo tanto, los cambios se agregaron originalmente para NeXTStep (el que finalmente se convirtió en Mac OS X), solo para configuraciones de enlace particulares. No conozco este sistema operativo, por lo que es difícil decir por qué se hizo; sospecho que fue simplemente para evitar conflictos de nombres. Por ejemplo, una biblioteca marco foo.so podría estar cargada y el sistema operativo no permitirá cargar otra biblioteca con el mismo nombre. Así que foomodule.so fue un compromiso para permitir que un módulo de Python con el nombre foo , sin embargo, exista.

Edit : el párrafo anterior estaba equivocado: no fui lo suficientemente lejos en la historia, gracias a Senderle por señalarlo. De hecho, el cambio interesante parece ser http://hg.python.org/cpython-fullhistory/diff/2230/Python/import.c desde 1994, que es donde se agregó un nuevo esquema de denominación de módulos ( foo.so ) como Una alternativa al esquema antiguo ( foomodule.so ). Supongo que la forma anterior quedó en desuso en algún momento dado que se ha eliminado el soporte para algunas plataformas como Windows en una de las numerosas reescrituras de ese código. Tenga en cuenta que incluso cuando se introdujo por primera vez, la versión del nombre corto del módulo se enumeró primero, lo que significa que ya era la variante preferida.

Edit2 : Busqué en la lista de correo / grupo de noticias de 1994 para ver si este cambio se discutió en algún lugar. No parece que lo fuera, Guido van Rossum parece haberlo implementado sin avisar a nadie.

Answer 2

Esto es simplemente una suposición, pero solo puedo asumir que esto está relacionado con lo siguiente, desde Extendiendo Python con C o C ++ .

Comience creando un archivo spammodule.c. (Históricamente, si un módulo se llama spam, el archivo C que contiene su implementación se llama spammodule.c; si el nombre del módulo es muy largo, como spammify, el nombre del módulo puede ser simplemente spammify.c).

Supongo que esta convención se extiende al nombre del archivo .so . Esa conjetura es apoyada por la sección 1.5 de la misma .

Basado en el excelente descubrimiento de Wladimir, he encontrado la primera referencia a module.so como un sufijo. Se trata de un parche para admitir la carga dinámica de las bibliotecas de SunOS, desde "Bill". (¿ Bill Jansson? ) Claramente, la convención del module como sufijo comenzó antes del uso de las bibliotecas compartidas .so , y cuando se adoptaron las bibliotecas .so , la convención simplemente se mantuvo.

Sin embargo, creo que Wladimir tiene razón: el cambio interesante es aquel en el que se adoptó la convención de nombre corto de módulo. Eso confirma mi suposición de que el nombre largo del módulo era la convención anterior.