✔️ Machine Learning Roadmap: нормальная карта входа в ML без сказок про «выучить нейросети за месяц»
Большой русскоязычный roadmap по машинному обучению: от первого import numpy до LLM, RAG, fine-tuning, AI-агентов и MLOps.
Внутри нормальная структура: что учить, в каком порядке, зачем это нужно и какой практический артефакт должен появиться после каждого этапа.
Roadmap разбит на 7 треков:
- фундамент: Python, математика, статистика, инструменты
- классический ML: scikit-learn, табличные данные, метрики, валидация
- Deep Learning: PyTorch, CNN, RNN, training loop
- LLM и трансформеры: attention, KV-cache, RAG, LoRA, агенты
- Generative AI: изображения, видео, аудио, мультимодальность
- MLOps и прод: Docker, Kubernetes, CI/CD, мониторинг, serving
- специализация: CV, NLP, RecSys, RL, Safety
Самое полезное - там честно написано, что ML это не только «обучить модель». В реальности большая часть работы живёт вокруг данных, метрик, деплоя, мониторинга, воспроизводимости и понимания, почему модель вообще ошибается.
Хорошая мысль из roadmap: LLM не делает джуна сениором. Она ускоряет того, кто понимает базу. Без базы человек просто превращается в оператора Copilot, который не может объяснить, почему модель сломалась.
По времени тоже без инфоцыганства:
- 0-3 месяца: Python, математика, классический ML
- 3-6 месяцев: Deep Learning и PyTorch
- 6-12 месяцев: LLM, RAG, fine-tuning, AI-агенты
- 12+ месяцев: MLOps, прод, масштабирование, специализация
Короче, если давно хотели системно зайти в ML, а не прыгать между роликами про ChatGPT, Stable Diffusion и «топ-10 библиотек», это хороший ориентир.
https://github.com/justxor/MachineLearningRoadmap/tree/main
@Python_Community_ru
Большой русскоязычный roadmap по машинному обучению: от первого import numpy до LLM, RAG, fine-tuning, AI-агентов и MLOps.
Внутри нормальная структура: что учить, в каком порядке, зачем это нужно и какой практический артефакт должен появиться после каждого этапа.
Roadmap разбит на 7 треков:
- фундамент: Python, математика, статистика, инструменты
- классический ML: scikit-learn, табличные данные, метрики, валидация
- Deep Learning: PyTorch, CNN, RNN, training loop
- LLM и трансформеры: attention, KV-cache, RAG, LoRA, агенты
- Generative AI: изображения, видео, аудио, мультимодальность
- MLOps и прод: Docker, Kubernetes, CI/CD, мониторинг, serving
- специализация: CV, NLP, RecSys, RL, Safety
Самое полезное - там честно написано, что ML это не только «обучить модель». В реальности большая часть работы живёт вокруг данных, метрик, деплоя, мониторинга, воспроизводимости и понимания, почему модель вообще ошибается.
Хорошая мысль из roadmap: LLM не делает джуна сениором. Она ускоряет того, кто понимает базу. Без базы человек просто превращается в оператора Copilot, который не может объяснить, почему модель сломалась.
По времени тоже без инфоцыганства:
- 0-3 месяца: Python, математика, классический ML
- 3-6 месяцев: Deep Learning и PyTorch
- 6-12 месяцев: LLM, RAG, fine-tuning, AI-агенты
- 12+ месяцев: MLOps, прод, масштабирование, специализация
Короче, если давно хотели системно зайти в ML, а не прыгать между роликами про ChatGPT, Stable Diffusion и «топ-10 библиотек», это хороший ориентир.
https://github.com/justxor/MachineLearningRoadmap/tree/main
@Python_Community_ru
🔒🌐 Awesome Privacy: Your Guide to Online Privacy Tools
Этот репозиторий собрал лучшие ресурсы и инструменты для обеспечения вашей конфиденциальности в интернете. Здесь вы найдете полезные ссылки на программы, сервисы и советы по защите личных данных.
🚀Основные моменты:
- Обширный список инструментов для защиты конфиденциальности
- Ресурсы по анонимности и безопасности в сети
- Регулярные обновления и новые добавления
- Полезные советы по улучшению личной безопасности
📌 GitHub:
#markdown
@Python_Community_ru
https://github.com/Lissy93/awesome-privacy
Этот репозиторий собрал лучшие ресурсы и инструменты для обеспечения вашей конфиденциальности в интернете. Здесь вы найдете полезные ссылки на программы, сервисы и советы по защите личных данных.
🚀Основные моменты:
- Обширный список инструментов для защиты конфиденциальности
- Ресурсы по анонимности и безопасности в сети
- Регулярные обновления и новые добавления
- Полезные советы по улучшению личной безопасности
📌 GitHub:
#markdown
@Python_Community_ru
https://github.com/Lissy93/awesome-privacy
GitHub
GitHub - lissy93/awesome-privacy: 🦄 A curated list of privacy & security-focused software and services
🦄 A curated list of privacy & security-focused software and services - lissy93/awesome-privacy
Вышел Codex CLI 0.133.0.
Goals теперь работают по умолчанию. У них появилось отдельное хранилище, прогресс трекается сквозь активные ходы, так что агент держит цель в фокусе между шагами и не забывает, куда шёл.
Заметно прокачали Permission profiles: API для списков, наследование настроек, поддержка managed requirements.toml, обновление прав в рантайме без перезапуска и усиленный сэндбокс под Windows.
Расширения получили доступ к событиям подагентов (старт, стоп), вызовам инструментов, метаданным хода и асинхронной обработке аппрувов. Можно строить нормальные обвязки вокруг Codex.
Плагины: discovery теперь учитывает маркетплейсы, показывает установленные версии, видимые корни и умеет работать с удалёнными коллекциями.
https://github.com/openai/codex/releases/tag/rust-v0.133.0
@Python_Community_ru
Goals теперь работают по умолчанию. У них появилось отдельное хранилище, прогресс трекается сквозь активные ходы, так что агент держит цель в фокусе между шагами и не забывает, куда шёл.
Заметно прокачали Permission profiles: API для списков, наследование настроек, поддержка managed requirements.toml, обновление прав в рантайме без перезапуска и усиленный сэндбокс под Windows.
Расширения получили доступ к событиям подагентов (старт, стоп), вызовам инструментов, метаданным хода и асинхронной обработке аппрувов. Можно строить нормальные обвязки вокруг Codex.
Плагины: discovery теперь учитывает маркетплейсы, показывает установленные версии, видимые корни и умеет работать с удалёнными коллекциями.
https://github.com/openai/codex/releases/tag/rust-v0.133.0
@Python_Community_ru
Kronos - open-source модель, которая читает финансовые свечи как язык
Это не обычная LLM, которую натянули на финансы. Kronos изначально обучали на K-line данных: open, high, low, close, volume и рыночных паттернах.
Что умеет:
- прогнозировать цену по свечам;
- оценивать будущую волатильность;
- работать zero-shot без дообучения;
- запускаться в разных размерах - от 4.1M до 499M параметров;
- делать прогнозы через несколько строк Python.
Модель обучали на данных с 45+ бирж, есть live demo для BTC/USDT, модели выложены на Hugging Face, код открыт под MIT.
Главная идея сильная: финансовые данные наконец начали обрабатывать не как обычный временной ряд, а как отдельный язык рынка.
GitHub: github.com/shiyu-coder/Kronos
@Python_Community_ru
Это не обычная LLM, которую натянули на финансы. Kronos изначально обучали на K-line данных: open, high, low, close, volume и рыночных паттернах.
Что умеет:
- прогнозировать цену по свечам;
- оценивать будущую волатильность;
- работать zero-shot без дообучения;
- запускаться в разных размерах - от 4.1M до 499M параметров;
- делать прогнозы через несколько строк Python.
Модель обучали на данных с 45+ бирж, есть live demo для BTC/USDT, модели выложены на Hugging Face, код открыт под MIT.
Главная идея сильная: финансовые данные наконец начали обрабатывать не как обычный временной ряд, а как отдельный язык рынка.
GitHub: github.com/shiyu-coder/Kronos
@Python_Community_ru
This media is not supported in your browser
VIEW IN TELEGRAM
🚀 PgQue – Устойчивые очереди в Postgres
PgQue предлагает универсальную архитектуру очередей для PostgreSQL, основанную на проверенной модели PgQ. Это решение без лишних зависимостей, работающее на любом управляемом Postgres, обеспечивая нулевое бремя и стабильную производительность под нагрузкой.
🚀 Основные моменты:
- Никаких внешних демонов или расширений
- Использует SQL и PL/pgSQL для установки
- Обеспечивает ACID-транзакции и долговечность
- Никакого накопления "мертвых" кортежей
- Подходит для высоконагруженных систем
📌 GitHub: https://github.com/NikolayS/pgque
#sql
@Python_Community_ru
PgQue предлагает универсальную архитектуру очередей для PostgreSQL, основанную на проверенной модели PgQ. Это решение без лишних зависимостей, работающее на любом управляемом Postgres, обеспечивая нулевое бремя и стабильную производительность под нагрузкой.
🚀 Основные моменты:
- Никаких внешних демонов или расширений
- Использует SQL и PL/pgSQL для установки
- Обеспечивает ACID-транзакции и долговечность
- Никакого накопления "мертвых" кортежей
- Подходит для высоконагруженных систем
📌 GitHub: https://github.com/NikolayS/pgque
#sql
@Python_Community_ru
🌟 Интуитивные голосовые интерфейсы с Moonshine Voice
Moonshine Voice — это открытый инструмент для разработчиков, позволяющий создавать голосовые приложения в реальном времени. Все работает на устройстве, обеспечивая высокую скорость и конфиденциальность без необходимости в учетных записях или API-ключах. Поддерживает множество языков и предлагает высокую точность распознавания речи.
🚀 Основные моменты:
- Оптимизирован для приложений с низкой задержкой.
- Поддержка множества платформ: от Python до IoT-устройств.
- Простые в использовании API для транскрипции и синтеза речи.
- Высокая точность моделей, превосходящая Whisper Large V3.
- Многоязычная поддержка для STT и TTS.
📌 GitHub: https://github.com/moonshine-ai/moonshine
#python
@Python_Community_ru
Moonshine Voice — это открытый инструмент для разработчиков, позволяющий создавать голосовые приложения в реальном времени. Все работает на устройстве, обеспечивая высокую скорость и конфиденциальность без необходимости в учетных записях или API-ключах. Поддерживает множество языков и предлагает высокую точность распознавания речи.
🚀 Основные моменты:
- Оптимизирован для приложений с низкой задержкой.
- Поддержка множества платформ: от Python до IoT-устройств.
- Простые в использовании API для транскрипции и синтеза речи.
- Высокая точность моделей, превосходящая Whisper Large V3.
- Многоязычная поддержка для STT и TTS.
📌 GitHub: https://github.com/moonshine-ai/moonshine
#python
@Python_Community_ru
🔥 AlphaProof Nexus: формальные доказательства начинают превращаться в инженерный пайплайн
Google DeepMind показали AlphaProof Nexus - систему, которая автономно закрыла 9 открытых задач Эрдёша, часть из которых висела десятилетиями. По оценке авторов, стоимость решения одной задачи составила всего несколько сотен долларов.
Кроме этого, система доказала 44 открытые гипотезы из OEIS, закрыла 15-летний вопрос в алгебраической геометрии и нашла новый алгоритмический параметр в оптимизационной теории, который раньше не был описан людьми.
Модель генерирует идеи и фрагменты доказательств, а Lean проверяет каждый логический шаг через компилятор. Если доказательство некорректно, оно просто не проходит проверку. Не нужен рецензент, который вручную ищет дыру в рассуждении.
Базовый агент, который просто чередует генерацию LLM и обратную связь от компилятора, смог повторить все 9 успешных решений задач Эрдёша. Более сложная версия с эволюционным поиском и reinforcement learning дала заметный выигрыш только на самых тяжёлых случаях.
Чем сильнее становятся foundation models, тем чаще простые циклы «сгенерировал - проверил - исправил» начинают догонять специализированные архитектуры.
Отличие от неформального подхода к математическим доказательствам принципиальное. Модель часто придумывала несуществующие леммы, ссылалась на «известные результаты» и пыталась спрятать сложность задачи в вспомогательное утверждение. В обычном текстовом доказательстве такие ошибки легко пропустить. Lean отсекает их сразу.
Ещё один неожиданный эффект: агент находил неточности в формализациях уже существующих математических утверждений. То есть он работал не только как решатель, но и как диагностический инструмент для самой постановки задачи.
Успехи пока сосредоточены там, где библиотека Lean уже достаточно зрелая: комбинаторика, теория чисел, оптимизация. Задачи, где нужно строить большой пласт новой теории, всё ещё далеко не закрыты. И большинство задач Эрдёша система не решила.
Та же схема подходит для кодигша, спецификаций, верификации протоколов, компиляторов, криптографии.
Формальная проверка отсекает галлюцинации.
Модель может придумать лемму или сослаться на несуществующий результат, но Lean это не пропустит.
@Python_Community_ru
Google DeepMind показали AlphaProof Nexus - систему, которая автономно закрыла 9 открытых задач Эрдёша, часть из которых висела десятилетиями. По оценке авторов, стоимость решения одной задачи составила всего несколько сотен долларов.
Кроме этого, система доказала 44 открытые гипотезы из OEIS, закрыла 15-летний вопрос в алгебраической геометрии и нашла новый алгоритмический параметр в оптимизационной теории, который раньше не был описан людьми.
Модель генерирует идеи и фрагменты доказательств, а Lean проверяет каждый логический шаг через компилятор. Если доказательство некорректно, оно просто не проходит проверку. Не нужен рецензент, который вручную ищет дыру в рассуждении.
Базовый агент, который просто чередует генерацию LLM и обратную связь от компилятора, смог повторить все 9 успешных решений задач Эрдёша. Более сложная версия с эволюционным поиском и reinforcement learning дала заметный выигрыш только на самых тяжёлых случаях.
Чем сильнее становятся foundation models, тем чаще простые циклы «сгенерировал - проверил - исправил» начинают догонять специализированные архитектуры.
Отличие от неформального подхода к математическим доказательствам принципиальное. Модель часто придумывала несуществующие леммы, ссылалась на «известные результаты» и пыталась спрятать сложность задачи в вспомогательное утверждение. В обычном текстовом доказательстве такие ошибки легко пропустить. Lean отсекает их сразу.
Ещё один неожиданный эффект: агент находил неточности в формализациях уже существующих математических утверждений. То есть он работал не только как решатель, но и как диагностический инструмент для самой постановки задачи.
Успехи пока сосредоточены там, где библиотека Lean уже достаточно зрелая: комбинаторика, теория чисел, оптимизация. Задачи, где нужно строить большой пласт новой теории, всё ещё далеко не закрыты. И большинство задач Эрдёша система не решила.
Та же схема подходит для кодигша, спецификаций, верификации протоколов, компиляторов, криптографии.
Формальная проверка отсекает галлюцинации.
Модель может придумать лемму или сослаться на несуществующий результат, но Lean это не пропустит.
@Python_Community_ru
✔️ Claude Code превращают в баг-хантинг машину
Claude-BugHunter - skill bundle для Claude Code, который добавляет готовую методологию для легального bug bounty, security audit и authorized red-team задач.
Это не один промпт в стиле «найди баги». Внутри целый набор рабочих навыков и команд:
- 51 skill и 15 slash-команд
- 574+ паттерна из раскрытых security-репортов
- 24 класса уязвимостей
- workflow для поиска, валидации, триажа и оформления findings
- шаблоны под enterprise-цепочки для M365, Okta, VMware и VPN-appliances
- scaffold папок под engagement: scope, notes, evidence, findings, reports
- интеграция с Burp через MCP
Проект: https://github.com/elementalsouls/Claude-BugHunter
@Python_Community_ru
Claude-BugHunter - skill bundle для Claude Code, который добавляет готовую методологию для легального bug bounty, security audit и authorized red-team задач.
Это не один промпт в стиле «найди баги». Внутри целый набор рабочих навыков и команд:
- 51 skill и 15 slash-команд
- 574+ паттерна из раскрытых security-репортов
- 24 класса уязвимостей
- workflow для поиска, валидации, триажа и оформления findings
- шаблоны под enterprise-цепочки для M365, Okta, VMware и VPN-appliances
- scaffold папок под engagement: scope, notes, evidence, findings, reports
- интеграция с Burp через MCP
Проект: https://github.com/elementalsouls/Claude-BugHunter
@Python_Community_ru
🖥 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