добавление импортов внутри testFramework (нормально делать import unittest)

importIfNeeded для моделей, которые подаются на вход функции

В джаве никогда такого не возникало, для питона это нормальная ситуация, которую надо обработать.

Переделать sys.path в import.

Возможное решение: разные наследники PythonImport, введение порядка на импортах, установка приоритетов. Часть логики уже написана, но за последний день мы не успели.

Конфликты имен переменных с модулями (или еще чем-нибудь)

Сейчас это делается через изменение existingVariableNames, это раскидано в нескольких местах в файлах PythonCg*.kt.

Можно сделать в CgContext отдельный контейнер для таких ситуаций, и учитывать его в CgNameGenerator.

Возможная проблема: мы можем сначала создать переменную, а потом импортировать модуль с таким именем. Возможное решение: редактировать Cg элементы уже созданных переменных.

Убрать if-ы из Cg... с Python -> (перенес логику из CgMethodConstructor в PythonCgMethodConstructor)

Перенести Python модели из Api.kt в PythonApi???

Все изменения положить в отдельные пакеты

Обработка исключений (writeWarningAboutFunction)

Чтобы сделать нормальную обработку, надо в UtExecutionFailure отказаться от хранения Throwable, заменить его на какую-то абстракцию.

Сейчас, чтобы можно было хоть как-то упаковывать UtExecutionFailure от питона, я его оборачиваю в Throwable("питоновское исключение"). Понятно, что с таким подходом оттуда еще какую-то информацию (подробное сообщение, stacktrace) не достать.

В текущей реализации кодогенератор решает, что функция и должна возвращать исключение, и поэтому комментарий сам не добавляет. Чтобы для питона хоть как-то понимать, что в тесте кидается исключение, я добавила в createTestMethod (который теперь находится в PythonCgMethodConstructor.kt) дополнительный комментарий, который бывает только при питоновской кодогенерации.

PythonTree <-> AssembleModel?

(совсем на будущее) Можно перенести генерацию временных питоновский скриптов (для запуска функции, для mypy) в общий кодогенератор?