В ходе некоторой работы, в которой я сейчас участвую, мне нужно было лучше понять содержимое файла .py, который создается при переносе C++ с помощью Swig. Это в контексте существующей системы (которую я не писал), которая добавляет некоторый пользовательский Python, который манипулирует содержимым globals()
в модуле. Пытаясь понять это, я понял, что даже не понимаю "нормального" кода, сгенерированного Swig.
Предположим, например, что мы создаем модуль MyModule, и в этом мы оборачиваем функцию C++ void f()
. В сгенерированном Swig файле Python MyModule.py появится следующее:
def f():
return _MyModule.f()
f = _MyModule.f
Мой вопрос: в чем смысл первых двух строк выше? Запись для 'f', добавляемая в MyModule globals()
этими первыми двумя строками, сразу же перезаписывается третьей строкой, которая, по моему мнению, по существу эквивалентна предыдущему def f()
.
Я что-то пропустил?
Ваш анализ верен - задание в третьей строке, которое вы показали, полностью скрывает первые два.
Это верно в простом случае, однако бывают случаи, когда этого не происходит. Возьмем, к примеру, этот файл SWIG:
%module test
%pythonprepend %{
#hello world
%}
void foo();
Здесь определение python для foo()
не скрывается, как в вашем примере, потому что в сгенерированной функции есть дополнительный код python. (Даже если это просто комментарий).
Я думаю, что причина, по которой определение всегда выбрасывается, а не просто когда это необходимо, вероятно, историческая, хотя я не могу найти точный пример из быстрого просмотра. SWIG поддерживает генерацию кода Python разными способами для множества разных версий Python. (См., Например, код, сгенерированный -builtin
, или вывод -python -help
чтобы получить некоторое представление о величине вариаций. Так что, вероятно, либо эти назначения когда-то были внутри теста времени выполнения, который был удален, когда он был устаревшим, и/или это похмелье из далекого прошлого.