🖥 Python умеет аккуратно читать вывод долгого процесса по мере выполнения
Вместо того чтобы ждать завершения команды, можно запустить её через subprocess.Popen и читать stdout построчно.
Так удобно следить за:
- долгими скриптами
- серверами
- сборками
- тестами
- CLI-утилитами
- фоновой обработкой данных
Пример на картинке запускает HTTP-сервер и сразу печатает его вывод:
subprocess.Popen(...) стартует процесс
stdout=subprocess.PIPE забирает поток вывода
iter(proc.stdout.readline, b'') читает строки, пока процесс жив
Полезный паттерн, когда нужно не просто запустить команду, а видеть, что с ней происходит прямо сейчас.
@Python_Community_ru
Вместо того чтобы ждать завершения команды, можно запустить её через subprocess.Popen и читать stdout построчно.
Так удобно следить за:
- долгими скриптами
- серверами
- сборками
- тестами
- CLI-утилитами
- фоновой обработкой данных
Пример на картинке запускает HTTP-сервер и сразу печатает его вывод:
subprocess.Popen(...) стартует процесс
stdout=subprocess.PIPE забирает поток вывода
iter(proc.stdout.readline, b'') читает строки, пока процесс жив
Полезный паттерн, когда нужно не просто запустить команду, а видеть, что с ней происходит прямо сейчас.
@Python_Community_ru
O(1) не значит «быстро»
Одна из самых частых ошибок в алгоритмах: считать, что O(1) всегда быстрее O(n).
На практике это не так.
O(1) означает только одно: время работы не растёт вместе с размером входных данных.
Но сама операция может быть дорогой.
Например, хеш-таблица формально даёт O(1) для поиска, но если данные не в кэше CPU, один cache miss может сделать её медленнее, чем простой линейный проход по маленькому массиву.
Именно поэтому в Go, Python и даже C-библиотеках для маленьких map/таблиц иногда используют обычный linear search.
Парадоксально, но:
O(n) при n = 16 и тёплом кэше может быть быстрее, чем O(1) с холодным cache miss.
Big O описывает асимптотический рост, а не реальную скорость на маленьких данных.
@Python_Community_ru
Одна из самых частых ошибок в алгоритмах: считать, что O(1) всегда быстрее O(n).
На практике это не так.
O(1) означает только одно: время работы не растёт вместе с размером входных данных.
Но сама операция может быть дорогой.
Например, хеш-таблица формально даёт O(1) для поиска, но если данные не в кэше CPU, один cache miss может сделать её медленнее, чем простой линейный проход по маленькому массиву.
Именно поэтому в Go, Python и даже C-библиотеках для маленьких map/таблиц иногда используют обычный linear search.
Парадоксально, но:
O(n) при n = 16 и тёплом кэше может быть быстрее, чем O(1) с холодным cache miss.
Big O описывает асимптотический рост, а не реальную скорость на маленьких данных.
@Python_Community_ru
⚡️ Как Redis считает миллиарды уникальных значений, почти не тратя память
Есть алгоритм HyperLogLog. Он позволяет примерно понять, сколько уникальных элементов прошло через систему, используя около 12 KB памяти.
Идея простая: Redis не хранит сами элементы.
Он делает так:
- берёт элемент
- считает от него хеш
- часть хеша использует как номер ячейки
- в другой части смотрит, сколько нулей подряд встретилось
- если новое число больше старого - обновляет ячейку
Почему это работает?
Потому что длинная серия нулей в хеше встречается редко.
Например:
- 1 ноль подряд - довольно часто
- 5 нулей подряд - уже реже
- 10 нулей подряд - примерно шанс 1 к 1024
- 20 нулей подряд - совсем редкое событие
Если Redis увидел очень редкий паттерн, значит через него, скорее всего, прошло много разных элементов.
В Redis используется 16 384 маленьких счётчика. Каждый хранит максимальную «редкость», которую видел для своей группы элементов.
Потом Redis объединяет эти значения математикой и получает оценку уникальных элементов.
Не точное число, а очень близкую оценку.
Главный прикол HyperLogLog:
он может обработать хоть миллионы, хоть миллиарды значений, но память почти не растёт.
Именно поэтому Redis умеет считать уникальных пользователей, IP, запросы или события без огромных таблиц и списков.
@Python_Community_ru
Есть алгоритм HyperLogLog. Он позволяет примерно понять, сколько уникальных элементов прошло через систему, используя около 12 KB памяти.
Идея простая: Redis не хранит сами элементы.
Он делает так:
- берёт элемент
- считает от него хеш
- часть хеша использует как номер ячейки
- в другой части смотрит, сколько нулей подряд встретилось
- если новое число больше старого - обновляет ячейку
Почему это работает?
Потому что длинная серия нулей в хеше встречается редко.
Например:
- 1 ноль подряд - довольно часто
- 5 нулей подряд - уже реже
- 10 нулей подряд - примерно шанс 1 к 1024
- 20 нулей подряд - совсем редкое событие
Если Redis увидел очень редкий паттерн, значит через него, скорее всего, прошло много разных элементов.
В Redis используется 16 384 маленьких счётчика. Каждый хранит максимальную «редкость», которую видел для своей группы элементов.
Потом Redis объединяет эти значения математикой и получает оценку уникальных элементов.
Не точное число, а очень близкую оценку.
Главный прикол HyperLogLog:
он может обработать хоть миллионы, хоть миллиарды значений, но память почти не растёт.
Именно поэтому Redis умеет считать уникальных пользователей, IP, запросы или события без огромных таблиц и списков.
@Python_Community_ru
This media is not supported in your browser
VIEW IN TELEGRAM
🖥 Python умеет читать бинарные файлы блоками очень элегантно - без ручного while True.
Вот такой приём через functools.partial:
`iter(partial(f.read, 64), b'')`
Что тут происходит:
partial(f.read, 64) превращает f.read(64) в функцию без аргументов.
iter(..., b'') вызывает её снова и снова, пока результат не станет b'', то есть пока файл не закончится.
В итоге получаем аккуратный цикл по блокам:
from functools import partial
with open("mydata.db", "rb") as f:
for block in iter(partial(f.read, 64), b""):
process_block(block)
@Python_Community_ru
Вот такой приём через functools.partial:
`iter(partial(f.read, 64), b'')`
Что тут происходит:
partial(f.read, 64) превращает f.read(64) в функцию без аргументов.
iter(..., b'') вызывает её снова и снова, пока результат не станет b'', то есть пока файл не закончится.
В итоге получаем аккуратный цикл по блокам:
from functools import partial
with open("mydata.db", "rb") as f:
for block in iter(partial(f.read, 64), b""):
process_block(block)
@Python_Community_ru
👍2
🖥 В России второй день подряд жалуются на проблемы с доступом к PyPI, главному репозиторию пакетов для Python. По данным Downdetector, сбои затрагивают пользователей из разных регионов.
PyPI для Python-разработчиков - это не просто сайт с библиотеками. Через него ставятся зависимости, фреймворки, CLI-утилиты и большая часть всего, что нужно для нормальной разработки. Когда он начинает отваливаться, ломается не «ещё один зарубежный сервис», а базовая инфраструктура языка.
Диагностика интернет-блокировок показала обрыв соединения на этапе TLS. Это момент, когда клиент и сервер пытаются установить защищённое соединение. Такое поведение похоже на блокировки через DPI, то есть глубокую инспекцию пакетов.
По симптомам ситуация напоминает недавние проблемы с доступом к DeepSeek, которые издание тоже связывало с похожим механизмом.
При этом в Роскомнадзоре утверждают, что PyPI не ограничивали и проблем с доступом к ресурсу не фиксируют, сообщает «Осторожно, новости».
Для разработчиков это неприятный сигнал. Даже если проблема окажется временным сбоем, зависимость от внешней инфраструктуры снова стала очень заметной: без PyPI внезапно сложнее собрать проект, поднять окружение, поставить зависимости и просто нормально работать с Python.
@Python_Community_ru
PyPI для Python-разработчиков - это не просто сайт с библиотеками. Через него ставятся зависимости, фреймворки, CLI-утилиты и большая часть всего, что нужно для нормальной разработки. Когда он начинает отваливаться, ломается не «ещё один зарубежный сервис», а базовая инфраструктура языка.
Диагностика интернет-блокировок показала обрыв соединения на этапе TLS. Это момент, когда клиент и сервер пытаются установить защищённое соединение. Такое поведение похоже на блокировки через DPI, то есть глубокую инспекцию пакетов.
По симптомам ситуация напоминает недавние проблемы с доступом к DeepSeek, которые издание тоже связывало с похожим механизмом.
При этом в Роскомнадзоре утверждают, что PyPI не ограничивали и проблем с доступом к ресурсу не фиксируют, сообщает «Осторожно, новости».
Для разработчиков это неприятный сигнал. Даже если проблема окажется временным сбоем, зависимость от внешней инфраструктуры снова стала очень заметной: без PyPI внезапно сложнее собрать проект, поднять окружение, поставить зависимости и просто нормально работать с Python.
@Python_Community_ru
🔥1🤔1
🖥 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 хорош не как самый быстрый исполнитель каждой операции.
Он хорош как удобный слой управления над быстрыми нативными кусками.
@Python_Community_ru
У 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 хорош не как самый быстрый исполнитель каждой операции.
Он хорош как удобный слой управления над быстрыми нативными кусками.
@Python_Community_ru
✔️ Centaur - это платформа для совместного использования AI-агентов, интегрированных в Slack.
Она позволяет командам взаимодействовать с агентами, которые выполняют задачи в изолированных средах Kubernetes, обеспечивая безопасность и гибкость.
🚀 Основные моменты:
- Slack-агенты для выполнения задач и получения ответов.
- Изолированные среды для безопасного выполнения команд.
- Поддержка пользовательских инструментов и плагинов.
- Долговременные рабочие процессы с возможностью восстановления.
- Хранение состояния для повторного подключения без потери данных.
📌 GitHub: https://github.com/paradigmxyz/centaur
#python
@Python_Community_ru
Она позволяет командам взаимодействовать с агентами, которые выполняют задачи в изолированных средах Kubernetes, обеспечивая безопасность и гибкость.
🚀 Основные моменты:
- Slack-агенты для выполнения задач и получения ответов.
- Изолированные среды для безопасного выполнения команд.
- Поддержка пользовательских инструментов и плагинов.
- Долговременные рабочие процессы с возможностью восстановления.
- Хранение состояния для повторного подключения без потери данных.
📌 GitHub: https://github.com/paradigmxyz/centaur
#python
@Python_Community_ru
GitHub
GitHub - paradigmxyz/centaur: Multiplayer, self-hosted, secure agents.
Multiplayer, self-hosted, secure agents. Contribute to paradigmxyz/centaur development by creating an account on GitHub.
🚀 GPU-библиотека для классического машинного обучения
FlashLib предлагает высокопроизводительные реализации операторов машинного обучения, таких как kmeans, PCA и DBSCAN, с использованием Triton и CuteDSL. Библиотека позволяет эффективно обрабатывать данные на GPU, обеспечивая простоту использования и высокую скорость выполнения.
🚀Основные моменты:
- Поддержка 15 высокоуровневых примитивов для машинного обучения.
- Информативный API для оценки производительности операций.
- Оптимизированные реализации для кластеризации, регрессии и декомпозиции.
- Легкая интеграция с PyTorch и sklearn.
📌 GitHub: https://github.com/FlashML-org/flashlib
#python
@Python_Community_ru
FlashLib предлагает высокопроизводительные реализации операторов машинного обучения, таких как kmeans, PCA и DBSCAN, с использованием Triton и CuteDSL. Библиотека позволяет эффективно обрабатывать данные на GPU, обеспечивая простоту использования и высокую скорость выполнения.
🚀Основные моменты:
- Поддержка 15 высокоуровневых примитивов для машинного обучения.
- Информативный API для оценки производительности операций.
- Оптимизированные реализации для кластеризации, регрессии и декомпозиции.
- Легкая интеграция с PyTorch и sklearn.
📌 GitHub: https://github.com/FlashML-org/flashlib
#python
@Python_Community_ru
GitHub
GitHub - FlashML-org/flashlib: Fast and memory-efficient classical machine learning operators
Fast and memory-efficient classical machine learning operators - FlashML-org/flashlib
Nex-N2 - новое любопытное семейство агентных моделей.
Что внутри:
- Adaptive Thinking - модель сама подбирает глубину рассуждения на каждом шаге
- экономия около 20% токенов без потери качества
- Coherent Thinking - единый формат мышления для поиска, кодинга и tool use
- меньше хрупких переключений между разными режимами работы
По заявлению команды, Nex-N2 показывает уровень Tier-1 open-source моделей на SWE-bench, Terminal-Bench, GDPval и других бенчмарках, приближаясь к GPT-5.5 и Opus 4.7.
Звучит мощно, но такие цифры стоит проверять независимыми прогонами.
- Kimi-K2.6: 86% - 13 из 14
- MiniMax: 100% - 8 из 8
- GLM-5.1: 100% - 13 из 13
- DeepSeek-V4-Pro: 92% - 11 из 12
- Opus 4.7: 45% - 5 из 11
- GPT-5.5: 30% - 3 из 10
🔗 https://nex-agi.com
📦 https://huggingface.co/nex-agi/Nex-N2-Pro
https://modelscope.cn/models/nex-agi/Nex-N2-Pro
https://github.com/nex-agi/Nex-N2
@Python_Community_ru
Что внутри:
- Adaptive Thinking - модель сама подбирает глубину рассуждения на каждом шаге
- экономия около 20% токенов без потери качества
- Coherent Thinking - единый формат мышления для поиска, кодинга и tool use
- меньше хрупких переключений между разными режимами работы
По заявлению команды, Nex-N2 показывает уровень Tier-1 open-source моделей на SWE-bench, Terminal-Bench, GDPval и других бенчмарках, приближаясь к GPT-5.5 и Opus 4.7.
Звучит мощно, но такие цифры стоит проверять независимыми прогонами.
- Kimi-K2.6: 86% - 13 из 14
- MiniMax: 100% - 8 из 8
- GLM-5.1: 100% - 13 из 13
- DeepSeek-V4-Pro: 92% - 11 из 12
- Opus 4.7: 45% - 5 из 11
- GPT-5.5: 30% - 3 из 10
🔗 https://nex-agi.com
📦 https://huggingface.co/nex-agi/Nex-N2-Pro
https://modelscope.cn/models/nex-agi/Nex-N2-Pro
https://github.com/nex-agi/Nex-N2
@Python_Community_ru
👍1
TerminalTextEffects - это Python-библиотека без внешних зависимостей для добавления анимированного текста прямо в терминал.
Что умеет:
- работает прямо в текущем терминале и не ломает привычный workflow
- поддерживает Xterm 256 и RGB HEX-цвета
- умеет сложное движение символов через кривые Безье и плавное ускорение
- эффекты можно настраивать через типизированный config dataclass
- CLI-аргументы генерируются автоматически из конфигурации
https://github.com/ChrisBuilds/terminaltexteffects
@Python_Community_ru
Что умеет:
- работает прямо в текущем терминале и не ломает привычный workflow
- поддерживает Xterm 256 и RGB HEX-цвета
- умеет сложное движение символов через кривые Безье и плавное ускорение
- эффекты можно настраивать через типизированный config dataclass
- CLI-аргументы генерируются автоматически из конфигурации
https://github.com/ChrisBuilds/terminaltexteffects
@Python_Community_ru
🔍 Обнаружение уязвимостей с помощью Audit
Audit — это агент для поиска уязвимостей, использующий 8-ступенчатую методологию, основанную на взаимодействии узких агентов и принципе "умышленного несогласия". Он интегрируется с Claude Pro и предлагает структурированные отчеты о безопасности.
🚀 Основные моменты:
- Многопоточность: узкие агенты работают параллельно для поиска уязвимостей.
- Умышленное несогласие: второй агент проверяет выводы первого.
- Отслеживание доступности: подтверждает, что уязвимости могут быть достигнуты злоумышленником.
- Обратная связь: находит новые задачи на основе обнаруженных уязвимостей.
📌 GitHub: https://github.com/evilsocket/audit
#python
@Python_Community_ru
Audit — это агент для поиска уязвимостей, использующий 8-ступенчатую методологию, основанную на взаимодействии узких агентов и принципе "умышленного несогласия". Он интегрируется с Claude Pro и предлагает структурированные отчеты о безопасности.
🚀 Основные моменты:
- Многопоточность: узкие агенты работают параллельно для поиска уязвимостей.
- Умышленное несогласие: второй агент проверяет выводы первого.
- Отслеживание доступности: подтверждает, что уязвимости могут быть достигнуты злоумышленником.
- Обратная связь: находит новые задачи на основе обнаруженных уязвимостей.
📌 GitHub: https://github.com/evilsocket/audit
#python
@Python_Community_ru
SQLModel использует аннотации типов Python, чтобы объединить Pydantic и SQLAlchemy и уменьшить дублирование кода при работе с SQL-базами.
* одна аннотация типа заменяет отдельные модели Pydantic и SQLAlchemy
* хорошо совместим с FastAPI, Pydantic и SQLAlchemy
* внутри работает на базе Pydantic и SQLAlchemy
* разумные настройки по умолчанию уменьшают количество шаблонного кода
https://github.com/fastapi/sqlmodel
@Python_Community_ru
* одна аннотация типа заменяет отдельные модели Pydantic и SQLAlchemy
* хорошо совместим с FastAPI, Pydantic и SQLAlchemy
* внутри работает на базе Pydantic и SQLAlchemy
* разумные настройки по умолчанию уменьшают количество шаблонного кода
https://github.com/fastapi/sqlmodel
@Python_Community_ru
Zero training needed, Image-to-LoRA(i2L) V2 уже вышел 🚀
Обновлённая версия i2L стала заметно мощнее: теперь она может превратить одно или несколько референсных изображений в style LoRA за один прямой проход, без отдельного обучения для кастомизации визуального стиля.
🌟 Что нового в V2:
* Совместимость: работает с разными базовыми моделями, включая Z-Image, Klein-4B и Hidream-O1.
* Скорость: прямое предсказание весов style LoRA без обучения.
* Точность стиля: высокая верность переноса стиля без утечки семантики.
* Контроль: явные веса открывают asymmetric CFG, смешивание стилей из нескольких референсов и управляемую генерацию.
* Архитектура: image encoder, обучаемые LoRA queries и compressed decoding heads, которые генерируют адаптированные матрицы.
🤖 Коллекция моделей: https://modelscope.ai/collections/DiffSynth-Studio/Image-to-LoRA-V2
🎠 Studio: https://modelscope.ai/studios/DiffSynth-Studio/Z-Image-i2L-V2
📄 Paper: https://modelscope.ai/papers/2606.13809
@Python_Community_ru
Обновлённая версия i2L стала заметно мощнее: теперь она может превратить одно или несколько референсных изображений в style LoRA за один прямой проход, без отдельного обучения для кастомизации визуального стиля.
🌟 Что нового в V2:
* Совместимость: работает с разными базовыми моделями, включая Z-Image, Klein-4B и Hidream-O1.
* Скорость: прямое предсказание весов style LoRA без обучения.
* Точность стиля: высокая верность переноса стиля без утечки семантики.
* Контроль: явные веса открывают asymmetric CFG, смешивание стилей из нескольких референсов и управляемую генерацию.
* Архитектура: image encoder, обучаемые LoRA queries и compressed decoding heads, которые генерируют адаптированные матрицы.
🤖 Коллекция моделей: https://modelscope.ai/collections/DiffSynth-Studio/Image-to-LoRA-V2
🎠 Studio: https://modelscope.ai/studios/DiffSynth-Studio/Z-Image-i2L-V2
📄 Paper: https://modelscope.ai/papers/2606.13809
@Python_Community_ru
This media is not supported in your browser
VIEW IN TELEGRAM
Python иногда может выглядеть как тёмная магия.
Вот однострочный quicksort через lambda:
q = lambda x: x and q([i for i in x[1:] if i x[0]])
Что тут происходит:
* берём первый элемент как pivot
* всё, что меньше или равно ему, рекурсивно сортируем слева
* сам pivot ставим в центр
* всё, что больше, рекурсивно сортируем справа
* если список пустой, возвращается пустой список
Работает красиво, но в продакшен так писать не надо. Это скорее пример того, насколько гибким может быть Python, чем нормальный стиль кода.
Минусы очевидные: плохая читаемость, рекурсия, лишние списки на каждом шаге и риск упереться в лимит рекурсии.
Но как демонстрация идеи quicksort в одну строку — выглядит эффектно.
@Python_Community_ru
Вот однострочный quicksort через lambda:
q = lambda x: x and q([i for i in x[1:] if i x[0]])
Что тут происходит:
* берём первый элемент как pivot
* всё, что меньше или равно ему, рекурсивно сортируем слева
* сам pivot ставим в центр
* всё, что больше, рекурсивно сортируем справа
* если список пустой, возвращается пустой список
Работает красиво, но в продакшен так писать не надо. Это скорее пример того, насколько гибким может быть Python, чем нормальный стиль кода.
Минусы очевидные: плохая читаемость, рекурсия, лишние списки на каждом шаге и риск упереться в лимит рекурсии.
Но как демонстрация идеи quicksort в одну строку — выглядит эффектно.
@Python_Community_ru
GLM-5.2 (https://t.me/ai_machinelearning_big_data/10339)теперь можно запускать локально.
2-битная версия сохраняет около 82% точности после сжатия модели с 1,51 ТБ до 238 ГБ, то есть размер уменьшили на 84%.
Запуск возможен на Mac с 256 ГБ памяти или на системах с достаточным объёмом RAM/VRAM.
GLM-5.2 называют самой сильной открытой моделью на данный момент.
Гайд: https://unsloth.ai/docs/models/glm-5.2
GGUF: https://huggingface.co/unsloth/GLM-5.2-GGUF
@Python_Community_ru
2-битная версия сохраняет около 82% точности после сжатия модели с 1,51 ТБ до 238 ГБ, то есть размер уменьшили на 84%.
Запуск возможен на Mac с 256 ГБ памяти или на системах с достаточным объёмом RAM/VRAM.
GLM-5.2 называют самой сильной открытой моделью на данный момент.
Гайд: https://unsloth.ai/docs/models/glm-5.2
GGUF: https://huggingface.co/unsloth/GLM-5.2-GGUF
@Python_Community_ru
🤔1
🐍 Python Парсинг: Большой продвинутый бесплатный курс
Полное практическое руководство по веб-скрейпингу на Python — от основ HTTP до production-grade пауков, обхода антибот-защит, асинхронности и проектирования надёжных пайплайнов. Каждый раздел содержит рабочие примеры, типовые ошибки и продвинутые практики.
https://github.com/justxor/Pythonparsing-/tree/main
@Python_Community_ru
Полное практическое руководство по веб-скрейпингу на Python — от основ HTTP до production-grade пауков, обхода антибот-защит, асинхронности и проектирования надёжных пайплайнов. Каждый раздел содержит рабочие примеры, типовые ошибки и продвинутые практики.
https://github.com/justxor/Pythonparsing-/tree/main
@Python_Community_ru
OpenMythos - open-source попытка теоретически реконструировать Claude Mythos, где все архитектурные ставки расписаны прямо в README.
По сути, OpenMythos это публичная гипотеза, которая ещё и запускается.
Что авторы считают основой Mythos?
Не глубокий стек уникальных слоёв, а Recurrent-Depth Transformer.
MoE с активацией около 5% параметров, поэтому общий размер модели скорее показывает объём хранения, а не реальную стоимость вычислений.
Loop-index positional embedding, чтобы каждая итерация работала как отдельная вычислительная фаза.
ACT halting, чтобы модель сама решала, когда ей достаточно “думать”, причём отдельно для каждого токена.
И ещё continuous latent thoughts, которые могут кодировать сразу несколько следующих шагов. По смыслу это похоже на breadth-first search внутри одного forward pass.
Источники идей тоже понятны: Parcae для стабильности, Universal Transformers для halting, DeepSeek для MoE routing.
GitHub:
http://github.com/kyegomez/OpenMythos
@Python_Community_ru
По сути, OpenMythos это публичная гипотеза, которая ещё и запускается.
Что авторы считают основой Mythos?
Не глубокий стек уникальных слоёв, а Recurrent-Depth Transformer.
MoE с активацией около 5% параметров, поэтому общий размер модели скорее показывает объём хранения, а не реальную стоимость вычислений.
Loop-index positional embedding, чтобы каждая итерация работала как отдельная вычислительная фаза.
ACT halting, чтобы модель сама решала, когда ей достаточно “думать”, причём отдельно для каждого токена.
И ещё continuous latent thoughts, которые могут кодировать сразу несколько следующих шагов. По смыслу это похоже на breadth-first search внутри одного forward pass.
Источники идей тоже понятны: Parcae для стабильности, Universal Transformers для halting, DeepSeek для MoE routing.
GitHub:
http://github.com/kyegomez/OpenMythos
@Python_Community_ru
⚡️ Linux Roadmap: подробный практический курс от нуля до уверенного администратора
Это пошаговый маршрут изучения Linux с упором на практику. Каждый раздел содержит объяснение «почему это устроено именно так», разбор команд и обязательные задания, которые нужно выполнить руками в терминале. Чтение без повторения навыка не даёт — держите терминал открытым рядом с этим текстом.
Как работать с этим курсом: идите сверху вниз, не перепрыгивайте разделы; каждую команду набирайте руками, а не копируйте; в конце каждого блока выполняйте задание; специально ломайте систему в виртуалке и чините — это лучший способ учиться.
https://github.com/justxor/linuxfullroadmap/
@Python_Community_ru
Это пошаговый маршрут изучения Linux с упором на практику. Каждый раздел содержит объяснение «почему это устроено именно так», разбор команд и обязательные задания, которые нужно выполнить руками в терминале. Чтение без повторения навыка не даёт — держите терминал открытым рядом с этим текстом.
Как работать с этим курсом: идите сверху вниз, не перепрыгивайте разделы; каждую команду набирайте руками, а не копируйте; в конце каждого блока выполняйте задание; специально ломайте систему в виртуалке и чините — это лучший способ учиться.
https://github.com/justxor/linuxfullroadmap/
@Python_Community_ru
Pew Research опубликовали свежий отчёт «Americans and AI 2026».
Только 16% американцев теперь ожидают, что ИИ принесёт пользу обществу в следующие 20 лет, а 40% считают, что ИИ навредит обществу за тот же период.
24% американцев используют чат-боты ежедневно: 12% - несколько раз в день, 4%, почти постоянно.
51% взрослых жителей США всё ещё вообще не пользуются ИИ-чат-ботами.
42% используют чат-боты для поиска информации, и это делает поиск главным сценарием применения.
38% работающих взрослых используют чат-боты для рабочих задач.
10% используют их для эмоциональной поддержки или советов, а 4% - для общения и чувства компании.
ChatGPT доминирует по уровню использования: 44% взрослых американцев сообщили, что пользовались им.
Дальше идут Gemini - 24%, Copilot — 17%, Meta AI — 14%, Grok — 8%, Claude — 6% и Character.ai — 3%.
Взрослые младше 50 лет примерно в два раза чаще пользуются ChatGPT, чем люди старшего возраста: 57% против 28%.
30% говорят, что чат-боты помогают им с продуктивностью, и только 5% считают, что они ей вредят.
28% говорят, что чат-боты помогают им оставаться в курсе событий, и только 5% считают, что они мешают этому.
60% взрослых жителей США читают ИИ-сводки в поиске. Это значит, что ИИ уже влияет на потребление информации даже у тех, кто может активно не пользоваться чат-ботами.
https://www.pewresearch.org/internet/2026/06/17/americans-and-ai-2026-chatbots-smart-devices-and-views-on-impact/
@Python_Community_ru
Только 16% американцев теперь ожидают, что ИИ принесёт пользу обществу в следующие 20 лет, а 40% считают, что ИИ навредит обществу за тот же период.
24% американцев используют чат-боты ежедневно: 12% - несколько раз в день, 4%, почти постоянно.
51% взрослых жителей США всё ещё вообще не пользуются ИИ-чат-ботами.
42% используют чат-боты для поиска информации, и это делает поиск главным сценарием применения.
38% работающих взрослых используют чат-боты для рабочих задач.
10% используют их для эмоциональной поддержки или советов, а 4% - для общения и чувства компании.
ChatGPT доминирует по уровню использования: 44% взрослых американцев сообщили, что пользовались им.
Дальше идут Gemini - 24%, Copilot — 17%, Meta AI — 14%, Grok — 8%, Claude — 6% и Character.ai — 3%.
Взрослые младше 50 лет примерно в два раза чаще пользуются ChatGPT, чем люди старшего возраста: 57% против 28%.
30% говорят, что чат-боты помогают им с продуктивностью, и только 5% считают, что они ей вредят.
28% говорят, что чат-боты помогают им оставаться в курсе событий, и только 5% считают, что они мешают этому.
60% взрослых жителей США читают ИИ-сводки в поиске. Это значит, что ИИ уже влияет на потребление информации даже у тех, кто может активно не пользоваться чат-ботами.
https://www.pewresearch.org/internet/2026/06/17/americans-and-ai-2026-chatbots-smart-devices-and-views-on-impact/
@Python_Community_ru
