Соглашение об именах имен общих объектов Python

Ответ 1

Это зависит от платформы, Python имеет разные суффиксы, которые он пытается в зависимости от операционной системы. Вот инициализация таблицы суффиксов в 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;

Таким образом, он объединяет два списка _PyImport_DynLoadFiletab и _PyImport_StandardFiletab. Последний более простой, он определяется как [".py", ".pyw", ".pyc"] в том же файле (вторая запись присутствует только в Windows). _PyImport_DynLoadFiletab определяется в различных файлах dynload_<platform>.c. В системах на основе Unix его значение равно [".so", "module.so"], для CygWin он определяет [".dll", "module.dll"], тогда как для OS/2 это [".pyd", ".dll"], а для Windows это просто [".pyd"].

Я просмотрел историю исходного кода и, наконец, пришел к этому изменению с 1999 года, которое, по-видимому, добавило "module.so" в качестве возможного суффикса: http://hg.python.org/cpython-fullhistory/diff/8efa37a770c6/Python/importdl.c. Таким образом, изменения были первоначально добавлены для NeXTStep (тот, который в конечном итоге стал Mac OS X), для конкретных настроек привязки. Я не знаю эту ОС, поэтому сложно сказать, почему это было сделано - я подозреваю, что это просто предотвращение конфликтов имен. Например. возможно, уже была загружена библиотека фреймов foo.so, и ОС не разрешит загружать другую библиотеку с тем же именем. Таким образом, foomodule.so был компромиссом, позволяющим тем самым поддерживать модуль Python с именем foo.

Изменить: абзац выше был неправильным - я не зашел достаточно далеко назад в истории, благодаря senderle, указав это. Фактически, интересное изменение выглядит как http://hg.python.org/cpython-fullhistory/diff/2230/Python/import.c с 1994 года, где была добавлена ​​новая схема именования модулей (foo.so) как альтернатив старой схеме (foomodule.so). Я полагаю, что старая форма в какой-то момент устарела, учитывая, что ее поддержка была удалена для некоторых платформ, таких как Windows, в одном из многочисленных переписаний этого кода. Обратите внимание, что даже когда он был впервые введен, короткая версия имени модуля была указана первыми, а это означает, что он уже был предпочтительным вариантом.

Edit2. Я искал список рассылки/группу новостей с 1994 года, чтобы узнать, обсуждалось ли это изменение где-то - похоже, это не так, Гвидо ван Россум, похоже, реализовал его, не сказав никому.

Ответ 2

Это просто предположение, но я могу только предположить, что это связано с ниже, от Расширение Python с C или С++.

Начните с создания файла spammodule.c. (Исторически, если модуль называется спамом, C файл, содержащий его реализацию, называется spammodule.c; если имя модуля очень длинное, например spammify, имя модуля может быть просто spammify.c.)

Я предполагаю, что это соглашение распространяется на имя файла .so. Эта гипотеза далее поддерживается разделом 1.5 тем же.

Основываясь на Wladimir отличном открытии, я нашел первую ссылку до module.so в качестве суффикса. Это из патча для поддержки динамической загрузки библиотек SunOS, из "Билла". (Bill Jansson?) Очевидно, что соглашение module -as-suffix началось до использования .so разделяемых библиотек, а когда .so библиотеки были приняты, соглашение просто поддерживалось.

Я думаю, что Владимир прав, хотя - интересное изменение - это то, в котором было принято короткое название названия модуля. Это подтверждает мою догадку, что имя длинного модуля было более ранним.