Python вопросы с собеседований

OvisOCR2 вышел на ModelScope. Это компактная OCR-модель на 0.8B параметров для page-level document parsing: на вход подаётся изображение страницы, на выходе получается структурированный Markdown в нормальном порядке чтения. Формулы модель отдаёт в LaTeX, таблицы в HTML, визуальные области помечает image tags с bbox-координатами. По заявленным результатам OvisOCR2 набрала 96.58 overall на OmniDocBench v1.6 и стала первой end-to-end моделью, которая заняла первое место в лидерборде, где раньше доминировали pipeline-системы. На PureDocBench тоже сильный результат: 75.06 Avg3. Это важнее, чем просто победа на одном бенчмарке, потому что документный парсинг давно страдает от переобучения под популярные наборы. Модель сделана на базе Qwen3.5-0.8B и дообучалась через SFT, RL и OPD. Для деплоя есть поддержка vLLM, лицензия Apache 2.0. https://modelscope.ai/models/ATH-MaaS/OvisOCR2

В regex 1.13 появился макрос regex!. Важно: это не compile-time regex. Он не компилирует регулярку на этапе сборки. Смысл другой: макрос закрывает частый паттерн, когда вы используете что-то вроде std::sync::LazyLock, чтобы регулярное выражение компилировалось примерно один раз, а не при каждом вызове. То есть вместо ручной обёртки вокруг lazy-инициализации теперь есть более удобный встроенный способ. PR: github.com/rust-lang/regex/pull/1371

Что выведет код?

t = ([],)

try:
    t[0] += [1]
except TypeError as e:
    print("Ошибка:", type(e).__name__)

print(t)

Многие думают:

Ошибка: TypeError
([],)

Но Python выведет:

Ошибка: TypeError
([1],)

Почему? `t` — tuple, его нельзя менять. Но внутри tuple лежит список, а список менять можно. Оператор `+=` сначала мутирует список: ```python [] -> [1] ``` А потом Python пытается записать результат обратно в tuple: ```python t[0] = ... ``` И вот тут падает `TypeError`. Итог странный: ошибка была, но данные уже изменились. Главный урок: immutable-контейнер не делает вложенные объекты immutable. Если внутри tuple лежит list, этот list всё ещё можно изменить.

Почему Python — основной язык в offensive security? Большинство задач в ИБ так или иначе упирается в скрипты: автоматизация, работа с сетью, парсинг, фаззинг, свои утилиты под конкретную инфраструктуру. Готовых инструментов часто недостаточно — нужен код, который можно написать и доработать под себя. Python для Пентестера от Codeby — курс для тех, кто уже знает Python на базовом уровне и хочет применять его в информационной безопасности. Что будет на курсе: ⏺️ООП и модули для работы с аргументами командной строки ⏺️работа с БД и файловой системой ⏺️многопоточность ⏺️сетевая работа на Python ⏺️фаззер, сканер портов, брутфорсер, парсер ⏺️криптография и работа с метаданными ⏺️разработка прикладного фреймворка Формат обучения: • 3,5 месяца / 112 ак. ч. (14 недель + 1 неделя на экзамен) • ДЗ с ручной проверкой куратором • итоговый дипломный проект на выбор Запись на ближайший поток открыта до 16 июля. При оплате курса сразу — скидка 30% ➡️Успейте записаться 🪧Бесплатная консультация: @CodebyAcademyBot

Что выведет этот код?

funcs = []

for i in range(3):
    funcs.append(lambda: i)

print([f() for f in funcs])

Многие думают:

[0, 1, 2]

Но Python выведет:

[2, 2, 2]

Почему? `lambda` не запоминает значение `i` в момент создания. Она запоминает саму переменную. Когда цикл закончился, `i` уже равно `2`. Поэтому все функции смотрят на одно и то же последнее значение. Правильный фикс: ```python funcs = [] for i in range(3): funcs.append(lambda i=i: i) print([f() for f in funcs]) ``` Теперь будет: ```python [0, 1, 2] ``` Хитрость простая: если создаёшь функцию в цикле — фиксируй значение через аргумент по умолчанию.

Шаринган разработчика: увидь, где код жрёт время, и бей туда Оптимизация на языке Итачи. Не улучшай всё подряд, сначала увидь настоящий bottleneck. Включаешь профилировщик cProfile, собираешь статистику, сортируешь по cumtime и бьёшь в самую дорогую функцию. build_report на 78% времени это не догадка, а факт из профиля. Меньше слепых правок, больше точных ударов. https://www.youtube.com/shorts/11O1Sadtcwc

🖥 Python-трюк: `iter()` умеет работать как цикл до стоп-сигнала Многие знают iter() только для списков, но у него есть второй режим:

iter(callable, sentinel)

Он вызывает функцию снова и снова, пока она не вернёт sentinel. Например, читать большой файл кусками без while True:

with open("video.mp4", "rb") as f:
    for chunk in iter(lambda: f.read(8192), b""):
        process(chunk)

Что происходит: • lambda читает по 8192 байта • когда файл закончится, read() вернёт b"" • цикл сам остановится Выглядит мелко, но это чистый и питоновский способ убрать вечные:

while True:
    chunk = f.read(8192)
    if not chunk:
        break

Редкая штука, которую приятно знать.

tracesage добавляет локальный tracing без инфраструктуры для LangChain/LangGraph-агентов всего в две строки. Он записывает каждый chain, tool call и LLM call в SQLite, а затем показывает запуск в браузере как live graph и timeline. Open source, установка через pip install, лицензия MIT. https://github.com/kjgpta/tracesage

Основы Git и GitHub за 30 секунд: настройка, коммиты, ветки, Pull Request GitHub пугает новичков не сложностью, а количеством команд, в которых легко утонуть в первый же день. Эта шпаргалка собирает весь базовый путь от пустого терминала до открытого Pull Request, чтобы не держать всё в голове и не гуглить каждый шаг. Сначала первая настройка: задаёшь имя и email, иначе коммиты уходят непонятно от кого. Дальше старт работы: клонируешь репозиторий, заходишь в папку и сразу создаёшь свою ветку под задачу. Потом ежедневный цикл, который повторяется каждый день: status, pull, add, commit, push. Проверил, обновил, добавил, закоммитил, отправил. Отдельно блок полезных команд на каждый день: log с графом, diff, stash, branch и переключение на main.

🖥 Редкий Python-трюк: `contextvars` вместо глобальных переменных в async-коде Хочешь, чтобы request_id, user_id или trace_id были доступны в любом месте кода, но без прокидывания через 20 функций? Не делай так:

current_user = None

В async-приложении это ловушка. Один запрос может перезаписать данные другого. Правильнее использовать contextvars:

from contextvars import ContextVar

request_id = ContextVar("request_id", default="-")

async def handler(req):
    token = request_id.set(req.headers["X-Request-ID"])
    try:
        await process_order()
    finally:
        request_id.reset(token)

async def process_order():
    print("trace:", request_id.get())

Почему это круто: 1. значение живёт внутри текущего async-контекста 2. параллельные запросы не смешиваются 3. не нужно таскать request_id по всем функциям 4. идеально для логов, tracing, middleware и background tasks Особенно полезно в FastAPI, aiohttp, Celery-like воркерах и сервисах с большим количеством async-задач. threading.local() был норм для потоков. contextvars - нормальный инструмент для современного async Python.

Один из главных мифов вокруг ИИ-кодинга: достаточно найти правильный промпт — и модель начнет писать хороший код Но на практике два разработчика могут отправить одинаковый запрос: «создай API для пользователей» — и получить совершенно разный результат. Один получит аккуратный FastAPI-сервис с типами, тестами и обработкой ошибок. Другой — код, который придется переписывать после первого изменения. Причина часто не в модели. LLM (большие языковые модели) не знает, как устроен ваш проект: какие архитектурные решения приняты, какие стандарты действуют и что команда считает качественным результатом. Поэтому стоит выстраивать вокруг ИИ тот же инженерный слой, который уже есть в обычной разработке: правила проекта, чек-листы, автоматические проверки и понятные критерии качества. На бесплатном вебинаре karpovꓸcourses «ИИ-агенты и профессиональная разработка на Python» Алексей Жиряков покажет вживую, почему ИИ-код ломается в реальных проектах и как это исправлять. Алексей — исполнительный директор в Сбере, занимается развитием генеративного ИИ, а до этого более 15 лет работал в backend-разработке и руководил инженерными командами. Будет живое демо поверх готового репозитория: как настроить процесс, получить более чистый типизированный код и использовать продакшен-подход вроде связки «дешевая модель пишет — дорогая ревьюит», которая помогает снижать стоимость генерации. Присоединяйтесь по ссылке, а после регистрации вы получите гайд «Почему ваш ИИ пишет не то: LLM против ИИ-агента»: https://clc.to/erid_2W5zFHfubtm Реклама. ООО «КАРПОВ КУРСЫ». ИНН 7811764627. erid: 2W5zFHfubtm

Разберем математику бесконечности Сатору Годжо, которая работает не как обычный щит. Он не просто останавливает удар в последний момент. Идея в том, что пространство между атакой и Годжо как будто делится на всё более маленькие отрезки. Сначала объект проходит половину расстояния. Потом половину оставшегося. Потом ещё половину. И так снова и снова. Математически это похоже на бесконечную сумму: одна вторая, одна четвёртая, одна восьмая, одна шестнадцатая. Объект всё ближе, но до контакта так и не доходит. На практике атака как будто замедляется почти до нуля. Чем ближе она к Годжо, тем сильнее падает её эффективная скорость. Поэтому Бесконечность — это не просто барьер. Это контроль пространства, где противник застревает в бесконечном приближении.

Скажи мне 5 главных слов: на GitVerse появилось зеркало PyPI! 😎 Все нужные Python‑пакеты живут на российской платформе для разработчиков GitVerse — вы не потеряете доступ к ним, даже если основной PyPI решит «повиснуть». А ещё такое зеркало — плюс к скорости: меньше сетевых прыжков — быстрее загрузка. Ставьте его как основной источник или держите как резерв. Тут рассказали, как подключить зеркало!

🐍 Python Парсинг: Большой продвинутый бесплатный курс Полное практическое руководство по веб-скрейпингу на Python — от основ HTTP до production-grade пауков, обхода антибот-защит, асинхронности и проектирования надёжных пайплайнов. Каждый раздел содержит рабочие примеры, типовые ошибки и продвинутые практики. https://github.com/justxor/Pythonparsing-/tree/main

Python Совет: как добавить watermark на график Matplotlib В Matplotlib водяной знак можно добавить прямо через fig.text(). Пример:

import matplotlib.pyplot as plt

fig = plt.figure(figsize=(5, 8))

fig.text(
    1, 0.15,
    "Mouse vs Python",
    fontsize=45,
    color="blue",
    ha="right",
    va="bottom",
    alpha=0.4,
    rotation=25
)

plt.show()

Что здесь важно: * fig.text() добавляет текст на всю фигуру, а не внутрь конкретной оси * alpha=0.4 делает watermark полупрозрачным * rotation=25 поворачивает надпись * ha и va управляют привязкой текста по горизонтали и вертикали Полезно для отчётов, графиков в блогах, внутренних дашбордов и картинок, которые могут разойтись без контекста.

В Python есть ловушка, на которой легко ошибиться. Смотрим код: t равен кортежу из трёх элементов: один, два и список три, четыре. То есть внутри tuple лежит обычный список. Дальше выполняется строка: к элементу t с индексом два прибавить список с числом пять. Проще говоря, Python берёт третий элемент кортежа и добавляет к нему пять. Третий элемент — это список три, четыре. Для списка операция плюс равно меняет объект на месте. Поэтому список сразу становится: три, четыре, пять. Но потом Python пытается записать результат обратно в t с индексом два, то есть обратно в третий элемент tuple. А tuple неизменяемый. Его элементы нельзя перезаписывать по индексу. Поэтому возникает TypeError. И вот тут главный подвох: ошибка произошла, но список уже успел измениться. Финальный результат: t равен кортежу: один, два, список три, четыре, пять. Вывод: tuple не даёт менять свою структуру, но не делает вложенные объекты неизменяемыми.

⚡️ Python иногда умеет выглядеть как тёмная магия. Вот однострочный quicksort через lambda:

q = lambda x: x and q([i for i in x[1:] if i <= x[0]]) + [x[0]] + q([i for i in x[1:] if i > x[0]])

Что тут происходит: * берём первый элемент как pivot * всё, что меньше или равно ему, рекурсивно сортируем слева * сам pivot ставим в центр * всё, что больше, рекурсивно сортируем справа * если список пустой, возвращается пустой список Работает красиво, но в продакшен так писать не надо. Это скорее пример того, насколько гибким может быть Python, чем нормальный стиль кода. Минусы очевидные: плохая читаемость, рекурсия, лишние списки на каждом шаге и риск упереться в лимит рекурсии. Но как демонстрация идеи quicksort в одну строку — выглядит эффектно.

38 лет считалось, что для разреженных графов алгоритм Дейкстры почти упёрся в потолок. Логика выглядела железно: - Дейкстра упорядочивает вершины по расстоянию - сортировка имеет нижнюю границу O(n log n) - значит, кратчайшие пути быстрее искать нельзя Но группа из 5 исследователей показала, что это ограничение можно обойти. Идея в том, чтобы не просто «ускорить очередь с приоритетами», а смешать подход Дейкстры с динамическим программированием в стиле Беллмана-Форда. Алгоритм делит множество вершин, сжимает frontier и не тратит время на полную сортировку там, где она не нужна. Результат: O(m log^(2/3) n) Это первое улучшение для направленных разреженных графов со времён Fibonacci heap в 1987 году. Tsinghua, Stanford, Max Planck. 17 страниц, которые ломают старое интуитивное объяснение про «Дейкстру быстрее нельзя».

Когда-то в Python файлы открывали вот так: f_obj = open(path, 'w') f_obj.write(some_data) f_obj.close() Код короткий, выглядит понятно, но есть проблема: если между open() и close() что-то упадёт, файл может остаться незакрытым. Поэтому приходилось руками оборачивать всё в try / finally, следить за закрытием ресурса и не забывать cleanup на ошибках. Потом в Python появился with, и этот бытовой ад стал намного чище: with open(path, 'w') as f_obj: f_obj.write(some_data) Теперь файл закроется автоматически, даже если внутри блока случится исключение. Это одна из тех фич Python, которые выглядят мелко, но сильно меняют стиль кода. with убирает ручное управление ресурсами и делает намерение очевидным: вот ресурс, вот область, где он нужен, после выхода из блока его надо корректно закрыть. Используется не только для файлов: - соединения с базой - lock'и - временные файлы - сетевые подключения - транзакции - любые объекты с контекстным менеджером Хороший Python-код часто начинается с простого правила: если ресурс надо открыть и потом закрыть, почти всегда нужен with. #python

Python не медленный. Медленным его часто делает ваш код. У Python есть странная репутация: стоит программе начать тормозить, виноват сразу язык. Но в реальности большая часть быстрых сценариев в Python работает не потому, что интерпретатор внезапно стал магическим, а потому что тяжёлая работа уходит ниже - в C, C++ или Rust. CPython написан на C. Многие встроенные операции тоже выполняются в C: - len() - list.append() - dict.get() - sum() - сортировка - операции со строками - часть работы со списками и словарями Когда вы вызываете list.append(), Python не крутит всю логику добавления элемента на уровне байткода. Он платит небольшой overhead за вызов, а дальше попадает в C-функцию внутри CPython. Медленный путь начинается там, где мы вручную гоняем данные по одному элементу:

total = 0

for x in data:
    total += x

На каждой итерации интерпретатор должен выполнить байткод, достать объект, проверить типы, сделать операцию, обновить значение и перейти к следующему элементу. Для маленьких списков это незаметно. Для миллионов элементов это уже цена, которую вы платите за каждую итерацию. Быстрый путь выглядит иначе:

total = sum(data)

Здесь цикл проталкивается внутрь реализации. Python остаётся удобной оболочкой, а основная работа выполняется ближе к нативному коду. С NumPy та же идея, только ещё жёстче:

total = np.sum(data)

Внутренний цикл почти не возвращается в Python. Массив обрабатывается внутри оптимизированного нативного кода, а обратно приходит уже готовый результат. Поэтому фраза «Python медленный» слишком грубая. Точнее так: Python-циклы дорогие C-циклы дешёвые built-in функции часто быстрее ручного кода NumPy быстрый не из-за синтаксиса, а потому что не гоняет каждый элемент через интерпретатор хороший Python-код старается как можно дольше оставаться внутри готовых операций и библиотек Оптимизация Python часто начинается не с переписывания проекта на Go или Rust, а с простого вопроса: можно ли убрать ручной цикл и отдать работу тому коду, который уже написан на C, C++ или Rust? Python хорош не как самый быстрый исполнитель каждой операции. Он хорош как удобный слой управления над быстрыми нативными кусками.