Соглашение об именах модулей общих объектов Python - PullRequest
Новая
       22

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

19 голосов
/ 12 июня 2011

Я написал модуль Python на C ++ и построил его как библиотеку общих объектов, и она работала нормально. Но, выяснив все это, я заметил (через strace), что Python ищет несколько разных вариантов import. В частности, когда я говорю import foo, Python ищет в следующем порядке:

  • foo (каталог)
  • foo.so
  • foomodule.so
  • foo.py
  • foo.pyc

Это все было довольно понятно, за исключением foomodule.so. Почему Python ищет все как name.so, так и namemodule.so? Это какой-то исторический артефакт? Я довольно долго искал и не придумал никаких объяснений, и мне остается только задаться вопросом, должен ли я называть свой модуль foomodule.so вместо foo.so. Кажется, в моей системе есть несколько существующих модулей Python, соответствующих каждому соглашению, поэтому я не могу не задаться вопросом, подразумевают ли разные имена что-то.

Ответы [ 2 ]

18 голосов
/ 30 июня 2011

Это на самом деле зависит от платформы, 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 попосмотрим, обсуждалось ли где-нибудь это изменение - похоже, что это не так, похоже, Гвидо ван Россум реализовал его, не сказав никому.

10 голосов
/ 12 июня 2011

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

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

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

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

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

...