⚡️ Python 3.14: ошибки стали понятнее, чем когда-либо
В новой версии язык стал не просто «ругаться» на ошибки, а объяснять их понятным человеческим языком — с подсказками, где проблема и как её исправить. Т
еперь вместо сухого
📚 Подробности на Хабр: https://habr.com/ru/articles/953410/
В новой версии язык стал не просто «ругаться» на ошибки, а объяснять их понятным человеческим языком — с подсказками, где проблема и как её исправить. Т
еперь вместо сухого
invalid syntax вы получите конкретное объяснение и даже намёк на решение.📚 Подробности на Хабр: https://habr.com/ru/articles/953410/
🔥8👍4❤3
⚡️ Вышел Python 3.14 — теперь с JIT, фритредингом и шаблонными строками
Python наконец официально стал многопоточным по-взрослому — и даже обзавёлся экспериментальным JIT-компилятором. Да, это уже не просто обновление, а настоящий апгрейд эпохи GIL.
Версия Python 3.14.0 вышла как стабильный релиз и принесла массу интересных новшеств — от улучшенной работы аннотаций до встроенной поддержки Zstandard и UUIDv7.
Главные фичи:
• PEP 779 — Free-threaded Python теперь официально поддержан (GIL больше не обязателен).
• PEP 750 — шаблонные строки t"", аналог f"", но для кастомных парсеров.
• PEP 649 — аннотации теперь вычисляются отложенно.
• PEP 784 — новый модуль compression.zstd (поддержка Zstandard).
• PEP 768 — интерфейс для внешних отладчиков без накладных расходов.
• uuid теперь поддерживает версии 6–8 и работает до 40% быстрее.
• macOS и Windows-билды теперь включают экспериментальный JIT.
• Впервые доступны официальные Android-сборки.
Python окончательно перестаёт быть «медленным, но удобным». С фритредингом, JIT’ом и оптимизированной памятью он всё больше приближается к C# и Java по скорости исполнения — сохраняя простоту синтаксиса.
Полный список нововведений
@python_for_devs
Python наконец официально стал многопоточным по-взрослому — и даже обзавёлся экспериментальным JIT-компилятором. Да, это уже не просто обновление, а настоящий апгрейд эпохи GIL.
Версия Python 3.14.0 вышла как стабильный релиз и принесла массу интересных новшеств — от улучшенной работы аннотаций до встроенной поддержки Zstandard и UUIDv7.
Главные фичи:
• PEP 779 — Free-threaded Python теперь официально поддержан (GIL больше не обязателен).
• PEP 750 — шаблонные строки t"", аналог f"", но для кастомных парсеров.
• PEP 649 — аннотации теперь вычисляются отложенно.
• PEP 784 — новый модуль compression.zstd (поддержка Zstandard).
• PEP 768 — интерфейс для внешних отладчиков без накладных расходов.
• uuid теперь поддерживает версии 6–8 и работает до 40% быстрее.
• macOS и Windows-билды теперь включают экспериментальный JIT.
• Впервые доступны официальные Android-сборки.
Python окончательно перестаёт быть «медленным, но удобным». С фритредингом, JIT’ом и оптимизированной памятью он всё больше приближается к C# и Java по скорости исполнения — сохраняя простоту синтаксиса.
Полный список нововведений
@python_for_devs
🔥13👏2🤩2👍1
😇 PEP 8 как религия: почему Python сам не соблюдает свои же правила?
Мысль проста: споры о стиле в Python часто сводятся к одному —
Так стоит ли вообще относиться к PEP 8 как к догме?
📚 Подробности на Хабр: https://habr.com/ru/articles/953412/
Мысль проста: споры о стиле в Python часто сводятся к одному —
snake_case против camelCase. Даже сам Python не следует своим же правилам. Так стоит ли вообще относиться к PEP 8 как к догме?
📚 Подробности на Хабр: https://habr.com/ru/articles/953412/
👍5🔥3❤2
⚡️ Python 3.14: теперь реально быстрый или всё ещё просто “удобный”?
Думаю, вы уже слышали: релиз Python 3.14 состоялся. Мемы про “самый быстрый Python в истории” уже гуляют по сети — но давайте разберёмся, действительно ли он стал быстрее, или это очередной “чуть быстрее, но всё равно медленно”.
🟣 CPython 3.14 стал примерно на 27% быстрее, чем 3.13 — особенно заметно на рекурсивных задачах вроде вычисления чисел Фибоначчи.
🟣 Точка невозврата, как выяснилось, была ещё в 3.11 — именно тогда Python перестал быть “черепахой”.
🟣 Новый free-threading интерпретатор (без GIL) наконец-то показывает смысл в многопоточных сценариях: в CPU-нагруженных задачах ускорение до 3×.
🟣 А вот JIT-компиляция пока “для галочки” — ускорения почти нет, местами даже хуже.
🟣 PyPy всё ещё читает всем нотации: в 5–18 раз быстрее, чем CPython. Rust — вне конкуренции (в 70 раз быстрее, но это уже другая лига).
Другими словами, если вы всё ещё на Python 3.10 — апгрейд обязателен. Если уже на 3.13 — можно подождать, но 3.14 порадует, особенно если у вас параллельные вычисления. А вот на JIT пока не стоит делать ставку — он явно в стадии “эксперимента”.
📊 На графиках выше видно, как версии Python ускорялись с каждым релизом — особенно на задачах вроде вычисления чисел Фибоначчи и сортировки пузырьком. Python 3.14 уверенно обгоняет 3.13 и оставляет старые релизы далеко позади.
Источник
@python_for_devs
Думаю, вы уже слышали: релиз Python 3.14 состоялся. Мемы про “самый быстрый Python в истории” уже гуляют по сети — но давайте разберёмся, действительно ли он стал быстрее, или это очередной “чуть быстрее, но всё равно медленно”.
Другими словами, если вы всё ещё на Python 3.10 — апгрейд обязателен. Если уже на 3.13 — можно подождать, но 3.14 порадует, особенно если у вас параллельные вычисления. А вот на JIT пока не стоит делать ставку — он явно в стадии “эксперимента”.
Источник
@python_for_devs
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥7⚡5🤩2👍1👏1
⚡️ Автоматический парсинг чеков с LlamaIndex и Pydantic
Команда Python for Devs подготовила перевод статьи о том, как с помощью LlamaIndex и Pydantic можно превратить сканы чеков в структурированные данные.
Минимум кода — и у вас готовый CSV для анализа.
📚 Подробности на Хабр: https://habr.com/ru/articles/953414/
Команда Python for Devs подготовила перевод статьи о том, как с помощью LlamaIndex и Pydantic можно превратить сканы чеков в структурированные данные.
Минимум кода — и у вас готовый CSV для анализа.
📚 Подробности на Хабр: https://habr.com/ru/articles/953414/
👍5🔥4❤1
⚙️ Как собрать свою RAG-систему — без облаков и подписок
Хватит искать PDF-ки по корпоративным чатам. Сегодня любую внутреннюю документацию можно превратить в умный поисковик, который реально понимает, о чём вы спрашиваете. И всё — на чистом open source, локально и бесплатно.
RAG (Retrieval-Augmented Generation) объединяет две вещи: поиск по документам и генерацию ответов на естественном языке. Идея простая — модель не “придумывает” из головы, а берёт контекст из ваших файлов и формирует точный ответ. Ни утечек данных, ни платных API.
В новой статье — 5 инструментов:
🟣 MarkItDown — конвертирует любые документы (PDF, Word, HTML) в чистый Markdown.
🟣 LangChain RecursiveCharacterTextSplitter — умно режет текст на логические куски, чтобы LLM мог работать с контекстом.
🟣 SentenceTransformers (multi-qa-mpnet-base-dot-v1) — генерирует эмбеддинги локально, без доступа к API.
🟣 ChromaDB — хранит векторы и обеспечивает быстрый поиск по смыслу (HNSW-поиск под капотом).
🟣 Ollama + Gradio — локальная LLM (например, Mistral, Llama 3) и веб-интерфейс с потоковой генерацией ответов.
На выходе — полноценный Q&A-интерфейс по вашим документам: спрашиваете “как работает декоратор в Python”, получаете структурированный ответ с примером и ссылкой на исходный фрагмент. Всё работает офлайн, на локальной машине.
📚 Подробности на Хабр: https://habr.com/ru/articles/955798/
Хватит искать PDF-ки по корпоративным чатам. Сегодня любую внутреннюю документацию можно превратить в умный поисковик, который реально понимает, о чём вы спрашиваете. И всё — на чистом open source, локально и бесплатно.
RAG (Retrieval-Augmented Generation) объединяет две вещи: поиск по документам и генерацию ответов на естественном языке. Идея простая — модель не “придумывает” из головы, а берёт контекст из ваших файлов и формирует точный ответ. Ни утечек данных, ни платных API.
В новой статье — 5 инструментов:
На выходе — полноценный Q&A-интерфейс по вашим документам: спрашиваете “как работает декоратор в Python”, получаете структурированный ответ с примером и ссылкой на исходный фрагмент. Всё работает офлайн, на локальной машине.
📚 Подробности на Хабр: https://habr.com/ru/articles/955798/
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥14❤4👍3
😍 Красивый код на LaTeX прямо из Python
У вас тоже бывало — написал шикарную формулу в Python, а на презентации она выглядит как набор странных скобок и звёздочек?
Так вот, теперь можно не страдать с ручным LaTeX — Python умеет сам превращать ваш код в аккуратные математические выражения.
Три способа оживить ваши формулы:
🟣 handcalcs — делает пошаговые вычисления с подстановками, будто вы решаете задачу на доске.
🟣 latexify-py — автоматически превращает функции Python в чистый LaTeX без всяких промежуточных расчётов.
🟣 SymPy — для тех, кто хочет работать не с числами, а с уравнениями: символы, интегралы, производные — всё в одном пакете.
Подробнее про эти инструменты читайте на Хабре
@python_for_devs
У вас тоже бывало — написал шикарную формулу в Python, а на презентации она выглядит как набор странных скобок и звёздочек?
Так вот, теперь можно не страдать с ручным LaTeX — Python умеет сам превращать ваш код в аккуратные математические выражения.
Три способа оживить ваши формулы:
Подробнее про эти инструменты читайте на Хабре
@python_for_devs
Please open Telegram to view this post
VIEW IN TELEGRAM
👍4❤2🔥2
Forwarded from AI for Devs
Как же я устал от тех, кто ссылается на ChatGPT
Вот реально, кажется, наступил новый уровень профессиональной лени. Ставишь задачу, человек уходит, потом приносит результат… а там мешанина из слов и/или кода. Спрашиваешь: “Ты сам то это читал?” — и получаешь в ответ: “Ааа, так это ChatGPT херню нагенерил…”
Ёпта. Я вижу, что это херня. Вопрос не в том, что сделал ChatGPT. Вопрос в том, почему ты решил, что это можно мне отправить не глядя? Неужели ты рельно думаешь, что я не знаю что такое ChatGPT и не в состоянии самостоятельно отправить в него запрос? Если бы мне нужен был ответ от ChatGPT, я бы не обращался к тебе.
Использовать ChatGPT — норм. Но проверять, понимать и фильтровать что он там нагенерил – долг того, кто обратился к ChatGPT. А если к тебе обратился человек, то и проверять он хочет результат от человека, а не от ChatGPT, иначе зачем ему обращаться к тебе?
Вот реально, кажется, наступил новый уровень профессиональной лени. Ставишь задачу, человек уходит, потом приносит результат… а там мешанина из слов и/или кода. Спрашиваешь: “Ты сам то это читал?” — и получаешь в ответ: “Ааа, так это ChatGPT херню нагенерил…”
Ёпта. Я вижу, что это херня. Вопрос не в том, что сделал ChatGPT. Вопрос в том, почему ты решил, что это можно мне отправить не глядя? Неужели ты рельно думаешь, что я не знаю что такое ChatGPT и не в состоянии самостоятельно отправить в него запрос? Если бы мне нужен был ответ от ChatGPT, я бы не обращался к тебе.
Использовать ChatGPT — норм. Но проверять, понимать и фильтровать что он там нагенерил – долг того, кто обратился к ChatGPT. А если к тебе обратился человек, то и проверять он хочет результат от человека, а не от ChatGPT, иначе зачем ему обращаться к тебе?
💯23👍8🔥4👏1
GitHub выкатили ежегодный Octoverse 2025: разработчиков теперь больше 180 миллионов, а новый аккаунт появляется буквально каждую секунду. Главный триггер этого бума? Бесплатный GitHub Copilot, который запустили в конце 2024-го. Привет всем вайбкодерам!)
А теперь — к тому, что важно Python-разработчикам.
Во-первых, Python впервые уступил первое место TypeScript’у, но не потому, что сдал позиции. Просто фронтенд и строгая типизация сейчас на пике популярности вместе с агентами и Copilot’ом. TypeScript — идеальный партнёр для ИИ, который пишет код: строгие типы помогают ограничить количество “галлюцинирующего” кода. А вот Python — всё так же король, когда речь про модели, пайплайны и экспериментальные среды. Он стал самым популярным языком во всех AI-ориентированных проектах на GitHub: 582 000 репозиториев (+50% за год) и рост Jupyter-ноутбуков на +75%.
Во-вторых, Python-экосистема — это теперь де-факто стандарт для ИИ. Всё, что связано с моделями, оркестрацией и инфраструктурой — строится именно на Python.
Ну и напоследок — GitHub сообщает: к 2030 году каждый третий новый разработчик будет из Индии. Там уже +5 миллионов за год, и прогноз — 57,5 миллиона к концу десятилетия. Cтарый мем про “индийский код” станет повседневностью?)
Короче, рост — это круто. Наверное.
Источник
@python_for_devs
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
👍4❤3🔥3😱1
Forwarded from AI for Devs
This media is not supported in your browser
VIEW IN TELEGRAM
Мем дня: на сайте AI World Clocks девять ИИ-моделей каждую минуту получают простейшее задание — сделать обычные аналоговые часы на HTML и CSS.
Казалось бы, что может быть сложного?)
Казалось бы, что может быть сложного?)
😁12👍4🔥3
🤔 Python 3.14 без GIL: что это значит для веб-разработки?
Последние месяцы в новостях про Python много говорили о скорости: сравнивали 3.14 с 3.13, спорили о бенчмарках, радовались снижению оверхеда. Но почти нигде не было упора на веб-разработку.
Новая статья, которую мы перевели, закрывает этот пробел — и делает это на реальных ASGI и WSGI-приложениях.
Если коротко по фактам: в Python 3.14 free-threaded режим перестал быть экспериментом и почти догнал «обычный» интерпретатор по оптимизациям — провал в производительности сократился с ~35% до 5–10%. Но в вебе абсолютная скорость чистого Python — не главное. Здесь решает конкурентность, а она упиралась в GIL десятилетиями. Масштабирование через воркеры, гигабайты памяти на процессы — всё это было больше про обход ограничений, чем про реальные потребности приложений.
Практические тесты это подтверждают. В ASGI-приложениях free-threaded версия почти не уступает по I/O, зато заметно экономит память: можно держать больше сервисов на одной машине, упираясь в CPU, а не в RAM. В WSGI-сценариях картина смешанная: огромный выигрыш на CPU-нагруженных эндпоинтах, но и заметный рост потребления памяти — возможно, вопрос того, как серверы и GC адаптируются к новой модели исполнения.
Главная мысль: free-threaded Python не столько «ускоряет веб», сколько упрощает и стабилизирует его. Меньше магии с потоками и процессами, меньше компромиссов ради GIL, более предсказуемое масштабирование. Для большинства веб-сервисов это уже сейчас выглядит практичным улучшением, а не экспериментальной фичей.
@python_for_devs
Последние месяцы в новостях про Python много говорили о скорости: сравнивали 3.14 с 3.13, спорили о бенчмарках, радовались снижению оверхеда. Но почти нигде не было упора на веб-разработку.
Новая статья, которую мы перевели, закрывает этот пробел — и делает это на реальных ASGI и WSGI-приложениях.
Если коротко по фактам: в Python 3.14 free-threaded режим перестал быть экспериментом и почти догнал «обычный» интерпретатор по оптимизациям — провал в производительности сократился с ~35% до 5–10%. Но в вебе абсолютная скорость чистого Python — не главное. Здесь решает конкурентность, а она упиралась в GIL десятилетиями. Масштабирование через воркеры, гигабайты памяти на процессы — всё это было больше про обход ограничений, чем про реальные потребности приложений.
Практические тесты это подтверждают. В ASGI-приложениях free-threaded версия почти не уступает по I/O, зато заметно экономит память: можно держать больше сервисов на одной машине, упираясь в CPU, а не в RAM. В WSGI-сценариях картина смешанная: огромный выигрыш на CPU-нагруженных эндпоинтах, но и заметный рост потребления памяти — возможно, вопрос того, как серверы и GC адаптируются к новой модели исполнения.
Главная мысль: free-threaded Python не столько «ускоряет веб», сколько упрощает и стабилизирует его. Меньше магии с потоками и процессами, меньше компромиссов ради GIL, более предсказуемое масштабирование. Для большинства веб-сервисов это уже сейчас выглядит практичным улучшением, а не экспериментальной фичей.
@python_for_devs
👍5🔥5❤3
В сообществе Python обсуждается радикальное предложение: сделать Rust обязательной зависимостью для сборки интерпретатора CPython к версии 3.17. Авторы инициативы утверждают, что это критически необходимо для устранения ошибок памяти и обеспечения потокобезопасности. Это ключевое условие для полноценной поддержки Python без глобальной блокировки GIL.
Внедрение планируется поэтапно: уже в 3.16 сборка будет требовать компилятор Rust, если не использовать специальный флаг отключения. Мнения Core Developers разделились: Стив Дауэр выступает против добавления новых зависимостей в ядро, тогда как Алекс Гейнор поддержал инициативу. Главный технический риск – проблема циклической зависимости, поскольку Rust сам использует Python для своей сборки.
Если Pre-PEP примут, это кардинально изменит порог входа в системную разработку Python. Знание Rust станет обязательным требованием, а C-расширения со временем перейдут в категорию легаси.
Источник
@python_for_devs
Please open Telegram to view this post
VIEW IN TELEGRAM
👍7⚡2🔥2❤1
Разработчик, много лет использующий SQLAlchemy, представил собственный ORM — SQLORM, рождённый из желания работать «ближе к базе» и избавиться от магии Unit of Work. В центре подхода — чистый SQL, вызываемый напрямую из Python-функций через докстринги, без скрытых транзакций и привязки объектов к сессии.
Например, SQL-функция здесь выглядит так:
@sql
def get_recent_orders(start_date, end_date):
"""
SELECT * FROM orders
WHERE created_at BETWEEN :start_date AND :end_date
ORDER BY created_at DESC
"""
А модели работают как лёгкий Active Record:
class User(Model):
id: int
name: str
email: str
# Запросы выполняются сразу — без Unit of Work
user = User.insert(name="Alice", email="[email protected]")
SQLORM позволяет выбирать данные из одной базы и вставлять в другую, не привязывая модели к конкретному движку. Модели следуют паттерну Active Record, поддерживают ленивую загрузку, связи и аннотации для генерации DDL. При этом ORM остаётся максимально тонкой оболочкой над DB-API и не пытается скрывать SQL под query builder’ом или DSL.
Проект уже имеет хорошую документацию и интеграцию с Flask.
@python_for_devs
Please open Telegram to view this post
VIEW IN TELEGRAM
👍17❤3🔥3
16 ноября 2005 года Адриан Холловейти объявил о первом релизе Django 0.90 — и вот, два десятилетия спустя, команда выпускает первый релиз-кандидат Django 6.0. Юбилей фреймворк встречает не с ностальгией, а с внушительной статистикой.
Вот что говорит двадцатилетняя история Django:
Django за 20 лет стал примером того, как выглядит действительно стабильный и зрелый фреймворк: без резких поворотов, с постепенными улучшениями и проработанными фикcами. И команда уверяет — следующие двадцать лет будут такими же продуктивными.
@python_for_devs
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥9👍7❤3
Андрей Карпаты (экс-директор по ИИ в Tesla) выложил llm-council — небольшой проект, в котором один запрос обрабатывают сразу несколько моделей.
Каждая генерирует свой ответ, после чего им показывают анонимные варианты друг друга. Модели критикуют, сравнивают и оценивают ответы, а итог формирует отдельная модель-«председатель», получающая весь контекст обсуждения.
Идея не нова, но масштаб личности заставил многих обратить внимание на этот проект (уже почти 4к звёзд на GitHub).
Карпаты использует этот подход для разбора сложных книг: LLM спорят о содержании глав, находят слабые места в аргументации друг друга и принимают коллективное решение. Интересно, что в таких «совещаниях» модели часто выбирают GPT-5.1 как наиболее качественный вариант, а Sonnet — как наименее полезный.
Код бэкенда для этого проекта небольшой, полностью на Python и легко читается.
@python_for_devs
Please open Telegram to view this post
VIEW IN TELEGRAM
❤4👍4🔥3😁1