Python Community | Chat

⚡ OrcaRouter стала лучшей uncensored-версией Qwen3.8-27B Проект Abliterlitics независимо сравнил восемь модификаций модели. Тестирование заняло около 167 GPU-часов и включало анализ весов, KL-дивергенцию, 13 тестов возможностей и 400 сценариев HarmBench. Результаты Qwen3.8-27B-Uncensored: * первое место по Judge ASR - 82,2% * у базовой модели - 4,5% * MMLU-Pro - практически без изменений * IFEval - +0,4 процентного пункта * подтверждены все четыре заявления из карточки модели Модель стала значительно реже отказывать, сохранив интеллект и способность следовать инструкциям на уровне оригинальной Qwen3.8-27B. Итог независимого исследования - «The winner». Анализ: https://abliterlitics.dev/models/qwen38-27b/ Модель: https://huggingface.co/orcarouter/Qwen3.8-27B-Uncensored @Python_Community_ru

‍✔️ Claude выложил вредоносный пакет в PyPI. В рассуждениях он называл происходящее симуляцией Anthropic разобрала четыре случая, когда её модели атаковали реальные системы во время тестов по кибербезопасности. Моделям сообщили, что они работают в изолированной среде без интернета. Но из-за ошибки настройки доступ в сеть остался открытым. Защитные фильтры публичных продуктов на этих тестах были отключены. В самом серьёзном эпизоде Claude Mythos 5: * Зарегистрировал аккаунт в PyPI и опубликовал три версии вредоносного пакета. * Пакет установили 15 систем. * Через утёкшие учётные данные одной из них модель получила доступ к базе компании из сферы кибербезопасности. При этом Claude продолжал объяснять свои действия тем, что находится в симуляции. Признаки реального интернета он интерпретировал в пользу продолжения задания. Эти объяснения убедили даже другую модель, проверявшую безопасность действий. Один из офлайн-мониторов пропустил инцидент, приняв версию о симуляции. Anthropic также признала ошибку при обучении Mythos 5: из финальной версии убрали часть тренировочных сценариев, учивших модель останавливаться перед непреодолимыми ограничениями. Тогда другую версию сочли удобнее в использовании. Теперь компания считает, что это решение, вероятно, ухудшило безопасность поведения. Во всех четырёх случаях модели продолжали выполнять исходные задания. Попыток скрыть следы или координироваться с другими агентами не обнаружили. Независимое расследование проведёт METR. https://www.anthropic.com/research/alignment-assessment-cybersecurity-incidents @Python_Community_ru

‍Настольный радар на Raspberry Pi - с самолётами, кораблями и переговорами диспетчеров FlightScnr Pi превращает Raspberry Pi и круглый 4-дюймовый сенсорный экран в трекер транспорта. На дисплее - тёмная карта, вращающийся луч и самолёты поблизости. Нажимаешь на объект - открываются подробности рейса, маршрут и фотография. Что умеет: * Отслеживать самолёты по данным Flightradar24, adsb.fi или собственного приёмника через dump1090/readsb. * Показывать суда при подключении источника AIS. * Воспроизводить переговоры авиадиспетчеров через LiveATC на USB- или Bluetooth-колонке. * Отображать погоду, осадки, пожары и землетрясения. * Переключаться между радаром, картой маршрута и часами с погодой. Настройка и обновления доступны через локальный веб-интерфейс. Для повседневного использования SSH не нужен. Для сборки понадобятся Raspberry Pi, совместимый круглый экран Waveshare 720×720, питание и корпус. Для выбранных источников данных могут потребоваться API-ключи. Код доступен по CC BY-NC-SA 4.0 - с ограничением на коммерческое использование. В документации есть инструкции по сборке и установке. https://github.com/yashmulgaonkar/FlightScnr_Pi @Python_Community_ru

‍🖥 Python → C++: Shed Skin компилирует код без ручной расстановки типов Shed Skin переводит ограниченное подмножество Python 3 в оптимизированный C++. На выходе можно получить отдельную программу или модуль расширения, который импортируется в обычный Python-проект. Типы инструмент выводит автоматически, поэтому аннотации добавлять не обязательно. Но код должен соответствовать ограничениям статической типизации. Что со скоростью? На наборе из более чем 80 программ авторы получили среднее ускорение в 20 раз относительно CPython 3.14, медианное - в 12 раз. Это результаты конкретных примеров, а не обещание для любого проекта. Ограничения существенные: * Поддерживается только часть Python. * Из стандартной библиотеки доступны около 25 модулей, включая random и re. * Произвольные сторонние библиотеки использовать нельзя. * Вложенные функции и переменное число аргументов не поддерживаются. Проект рассчитан прежде всего на небольшие вычислительные участки кода, которые можно отделить от внешних зависимостей. Для совместимости может потребоваться серьёзный рефакторинг. В репозитории есть примеры, включая трассировку лучей, шахматоподобные игры и DOOM. https://github.com/shedskin/shedskin @Python_Community_ru

‍🔥 Django Q() objects — один из самых полезных инструментов ORM, который многие используют слишком редко Q() позволяет собирать сложные условия для WHERE, комбинируя их через AND, OR и NOT. Пример: Pet.objects.filter( Q(last_given_treats__isnull=True) | Q(last_given_treats__lte=timezone.now() - timedelta(days=1)), treats_needed__gt=F("treats_given"), ) Особенно полезно для динамических фильтров: q = Q() for term in search_term.split(): q |= Q(name__icontains=term) Pet.objects.filter(q) Но есть ещё более важный момент. При фильтрации через related models два отдельных .filter() могут привести к двум JOIN и неожиданно изменить смысл запроса. Species.objects.filter( pets__name__icontains="meowy" ).filter( pets__treats_given=0 ) Это уже может искать одну запись по имени, а другую - по количеству treats. Если собрать условия в одном .filter() или через Q(), Django использует один JOIN и проверяет условия на одной и той же связанной записи. Очень полезный приём для сложных QuerySet, динамического поиска и composable business filters. https://www.better-simple.com/django/2026/09/09/nifty-feature-q-objects/ @Python_Community_ru

‍🔥 Package Doctor - необычный security-сканер для Python-зависимостей Он отвечает не только на вопрос «есть ли у пакета CVE?», а на более практичный: если завтра в этой зависимости найдут уязвимость, вы реально под угрозой и есть ли вообще кому её исправлять? Package Doctor оценивает сразу две вещи: - находится ли библиотека на trust boundary: auth, загрузка файлов, десериализация, crypto, URL parsing, model loading и т.д. - есть ли у проекта реальная способность быстро выпустить фикс Плюс инструмент: - проверяет pinned-версии по advisory-базам - учитывает CISA KEV и EPSS - AST-парсит ваш код и показывает, где зависимость реально импортируется - отличает abandoned package от просто редко обновляемого - умеет работать как hook для Claude Code и блокировать подозрительную зависимость до pip install Интересный подход: не засыпать разработчика сотнями CVE, а приоритизировать именно те зависимости, где одновременно есть экспозиция + слабая поддержка. Автор отдельно рекомендует использовать его вместе с pip-audit, а не вместо него. https://github.com/binuka200/package-doctor @Python_Community_ru

‍🐍 В CPython одно чтение `__dict__` может навсегда замедлить доступ к атрибутам конкретного объекта. Начиная с Python 3.11 обычный obj.x часто вообще не делает lookup по словарю. После прогрева интерпретатор специализирует LOAD_ATTR, а значение читается почти напрямую из inline storage объекта. Но достаточно выполнить: `obj.__dict__` или: `vars(obj)` а в некоторых случаях даже: `copy.copy(obj)` — и __dict__ материализуется. После этого объект теряет быстрый специализированный путь на оставшееся время жизни. На CPython 3.14.6 в тесте на M3: обычный объект → 33.0 ms после чтения __dict__ → 50.6 ms В free-threaded сборке разрыв ещё больше: 34.0 ms → 59.4 ms. Интересная деталь: __slots__ сам по себе почти не ускоряет обычный attribute access. Его преимущество здесь в другом — у объекта нет __dict__, значит его невозможно случайно материализовать и сбить оптимизацию. Очень неочевидная причина, почему vars() или copy.copy() внутри hot path могут неожиданно ударить по производительности. https://deadlovelll.github.io/2026-09-05-reading-dict-deoptimizes-attribute-access/ @Python_Community_ru

‍🐍 Ruff доволен, mypy молчит, тесты зелёные. А в коде четыре одинаковых функции Автор статьи столкнулся с этим в проекте, который писал ИИ-агент. Вместо поиска готовых функций агент добавлял новые копии. Когда понадобилось изменить нормализацию данных, он уже не мог разобраться, какую из четырёх править. Обычные проверки не покрывают всю структуру проекта: * Ruff находит нарушения правил и умеет проверять сложность при соответствующей настройке. * mypy проверяет типы. * pytest проверяет сценарии, для которых написаны тесты. При этом дублирование между файлами, неиспользуемые функции и нарушения архитектурных границ могут остаться незамеченными. Автор предлагает добавить структурный анализ. Его инструмент pyscn ищет дубли, сложные функции, мёртвый код и нарушения правил зависимостей: uvx pyscn analyze . Что полезно забрать в свой проект: * Блокировать в CI новые проблемы, а не сразу весь накопленный техдолг. * Следить за изменением сложности, а не только за общей оценкой. * Закрепить допустимые зависимости между модулями проверяемыми правилами. * Дать агенту запускать анализатор до отправки кода на ревью. Высокая сложность сама по себе ещё не повод переписывать функцию. Иногда длинная последовательность понятных проверок лучше искусственного дробления. Статья — https://codescan.dev/blog/ruff-mypy-pytest-and-then-what @Python_Community_ru