Зачем нам «выкапывать» функции из кучи кода?

Вы когда‑нибудь пытались автоматизировать проверку решений студентов или быстро собрать кусок кода из большого репозитория? Если да, то знаете, как часто встречаются «запутанные» файлы‑мусорщики, где нужная функция спрятана между импортами и тестовыми блоками. Ниже – практичный набор инструментов, которые помогут вытянуть нужную функцию, проверить её синтаксис, обеспечить безопасность и прогнать юнит‑тесты без риска «выстрелить» в продакшн.

1. Как вытащить источник функции?

Функция extract_function_source принимает весь текст файла и имя функции, а возвращает только её исходный код. Основные шаги:

• Нормализуем переносы строк.
• Если в тексте присутствует fenced‑code‑block (`python … `), берём только его – удобно при парсинге markdown‑файлов.
• Ищем строку def <имя функции>( и собираем последующие строки, пока не наткнёмся на начало другой функции, класса, блока if __name__ == "__main__" или «грубой» присвоения.
• Пробуем распарсить полученный кусок через ast.parse. Если синтаксис сломан, пошагово восстанавливаем код до первого валидного состояния.

Итог – чистый, готовый к выполнению кусок кода, который можно передать в exec без лишних «мусорных» строк.

2. Проверка синтаксиса

Функция syntax_ok просто пытается собрать AST и сообщает, всё ли в порядке. Возвращает булево значение и сообщение об ошибке – удобно для быстрых «smoke‑тестов».

3. Статическая безопасность

Запуск пользовательского кода в продакшн‑окружении – плохая идея, если вы не уверены в его чистоте. static_safety_check сканирует AST и отсекает:

• Запрещённые имена (eval, exec, open и т.п.) и любые двойные подчёркивания.
• Опасные узлы дерева: Import, ClassDef, With, AsyncFunctionDef и др.
• Вызовы запрещённых функций.

Если всё ОК – вы получаете зелёный свет и причину отказа в случае проблемы.

4. Ограниченный набор встроенных функций

Для безопасного выполнения кода мы передаём в exec словарь ALLOWED_BUILTINS. В него попали только «тривиальные» функции (len, sum, range и т.д.), а всё, что может изменить файловую систему или окружение, исключено.

5. Запуск юнит‑тестов в изоляции

Функция run_unit_tests_safely делает три вещи:

• Проводит статический чек (см. выше). Если код небезопасен – сразу возвращает ошибку.
• Создаёт отдельный процесс (через multiprocessing с контекстом fork) и в нём компилирует и исполняет код.
• Запускает набор тестов, сравнивая реальный результат с ожидаемым, собирает детали и возвращает отчёт.

Таймаут (по умолчанию 3 секунд) защищает от бесконечных циклов, а очередь гарантирует, что вы получите результат даже если процесс упадёт.

6. Оценка сложности кода

Для тех, кто любит метрики, code_complexity использует pygount (или аналогичный cc_visit) и возвращает максимальную цикломатическую сложность. В системе баллов (функция score_candidate) учитываются:

• Синтаксическая корректность (1 балл).
• Проверка безопасности (1 балл).
• Процент пройденных тестов (до 3 баллов).
• Штраф за сложность (до 0,25 балла).

Таким образом, получаем целостную оценку качества решения.

7. Как это собрать в дело?

Ниже минимальный «скелет» применения:

import ast, re, multiprocessing as mp
from your_module import (
    extract_function_source,
    syntax_ok,
    static_safety_check,
    run_unit_tests_safely,
    score_candidate,
)
source_code = open('my_student_solution.py').read()
func_name = 'solve'
1️⃣ Выделяем функцию
func_source = extract_function_source(source_code, func_name)
2️⃣ Проверяем синтаксис и безопасность
if not syntax_ok(func_source)[0]:
raise ValueError('Синтаксис не прошёл проверку')
if not static_safety_check(func_source)[0]:
raise ValueError('Код небезопасен')
3️⃣ Тестируем
tests = [
{"args": [1, 2], "expected": 3},
{"args": [5, 7], "expected": 12},
]
result = run_unit_tests_safely(func_source, func_name, tests)
4️⃣ Оцениваем
final_score = score_candidate(func_source, result)
print('Score:', final_score)

И всё – ваш код «взят», проверен и оценён. Осталось лишь интегрировать эту цепочку в CI/CD, LMS или ваш собственный сервис.

8. Где найти готовый код

Исходники и примеры находятся в открытом репозитории на GitHub: github.com/yourorg/safe-code-evaluator. Там же вы найдёте README с инструкциями по установке и расширению списка разрешённых встроенных функций.

9. Заключительные мысли

Автоматическая оценка кода – это не магия, а набор чётких правил:

• Извлекать только нужное, ничего лишнего.
• Гарантировать, что код «не взорвет» сервер.
• Тестировать и оценивать в репрезентативных условиях.

Следуя этим принципам, вы избавитесь от головной боли, связанной с «неуправляемыми» кусками кода, и сможете сосредоточиться на том, что действительно важно – обучении и качестве продукта.