Понимание Swig сгенерированного файла Python

1

В ходе некоторой работы, в которой я сейчас участвую, мне нужно было лучше понять содержимое файла .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

1 ответ

0

Ваш анализ верен - задание в третьей строке, которое вы показали, полностью скрывает первые два.

Это верно в простом случае, однако бывают случаи, когда этого не происходит. Возьмем, к примеру, этот файл SWIG:

%module test

%pythonprepend %{
#hello world
%}

void foo();

Здесь определение python для foo() не скрывается, как в вашем примере, потому что в сгенерированной функции есть дополнительный код python. (Даже если это просто комментарий).

Я думаю, что причина, по которой определение всегда выбрасывается, а не просто когда это необходимо, вероятно, историческая, хотя я не могу найти точный пример из быстрого просмотра. SWIG поддерживает генерацию кода Python разными способами для множества разных версий Python. (См., Например, код, сгенерированный -builtin, или вывод -python -help чтобы получить некоторое представление о величине вариаций. Так что, вероятно, либо эти назначения когда-то были внутри теста времени выполнения, который был удален, когда он был устаревшим, и/или это похмелье из далекого прошлого.

Ещё вопросы

Сообщество Overcoder
Наверх
Меню