12 Python-библиотек для бесплатных рыночных данных, которые стоит знать каждому:

🔸yfinance
Данные по акциям: история, внутридневные котировки, фундаменталка. Плюс FX, крипта и опционы. Юзает Yahoo Finance, так что все данные оттуда доступны через yfinance.

🔸pandas-datareader
Раньше был частью pandas, теперь отдельный проект. Данные по акциям, валютам, экономическим индикаторам, факторам Фама-Френча и много чего еще.
Документация: https://pandas-datareader.readthedocs.io/en/latest/

🔸IBApi
Официальный API Interactive Brokers с доступом ко всем их данным. Пришел на замену IBPy.
Документация: https://interactivebrokers.github.io/tws-api/

🔸Alpha Vantage
Бесплатный API с реальными котировками и популярными финансовыми индикаторами. Формат JSON или CSV.

🔸Nasdaq Data Link (бывший Quandl)
Миллионы финансовых и экономических датасетов от сотен источников прямо в Python.

🔸Twelve Data
Доступ к 100000+ тикеров по акциям, форексу, индексам и фундаментальным данным со всего мира.

🔸Polygon.io
Реальные и исторические данные по акциям, валютам и криптовалютам.

🔸Tradier
Python-библиотеки для работы с Tradier API.

🔸alpaca-py
Все, что угодно: от стриминга рыночных данных до разработки своих инвест-приложений.

🔸Finnhub
Реалтайм REST API и вебсокеты для акций, валют и крипты.

🔸marketstack
Внутридневные и исторические данные за 30+ лет, 170000+ тикеров.
Документация: https://marketstack.com/documentation

🔸Tiingo
API с котировками на конец дня. Ставка на надежность, прозрачность и полноту.
Документация: https://api.tiingo.com/documentation/general/overview

👉 @PythonPortal

Deepnote уходит в open source и серьезно наезжает на Jupyter. Платформа предлагает мощный kernel с полной обратной совместимостью, но заметно более современный опыт работы с ноутбуками. Это все тот же формат для исследований данных и быстрой аналитики, только с нормальными версиями, комментариями, ревью и красивыми диффами.

В одном workspace могут спокойно работать и дата-инженеры, и менеджеры. Можно писать на Python, SQL или R, подключать сотни источников данных и даже собирать логику из no-code блоков вместе с AI-агентом. Поддерживается работа через VS Code, Cursor, Windsurf и JupyterLab. Интерфейс свежий, не из прошлого десятилетия. И да, .ipynb полностью гоняется туда-обратно.

Если Jupyter и дальше будет стоять на месте, Deepnote может занять его место уже в ближайшие годы. 👀

👉 @PythonPortal

Как вам такое

👉 @PythonPortal

🔥Прими участие в Хакатоне от ИТ-холдинга Т1 в Москве и поборись за призовой фонд 1 200 000 рублей!

Когда: 25–28 ноября
Формат: онлайн + финал на площадке

Участвуй, если ты:
🔹обучаешься на технической или ИТ-специальности
🔹развиваешься в направлении разработки, системной администрации, AI/ML или DevOps
🔹сможешь быть в Москве 28 ноября.

Выбери свой кейс:

✴️VibeCode Jam: собеседование будущего. Создай ИИ-платформу для прохождения технических собеседований с виртуальным интервьюером.

✴️Self-Deploy: CI/CD без DevOps. Автоматизируй генерацию CI/CD пайплайнов по анализу структуры Git-репозитория.

Почему стоит участвовать:
🔘Кейс в портфолио и полезная обратная связь от менторов Т1
🔘Шанс проявить себя, чтобы начать карьеру в одной из крупнейших ИТ-компаний
🔘Реальный опыт командной работы
🔘Мерч и атмосфера сильного комьюнити — в Т1 более 5 000 джунов из 580+ вузов России и Беларуси.

Регистрация открыта!
➡️ Успей до 23 ноября по ссылке.

Реклама.
О рекламодателе.

«Это же Python.. что ни сделай - всё в итоге аллоцируется».

Насколько это правда?

Разработчик внёс правку в CPython, чтобы логировались все аллокации объектов int. Затем запустил простой цикл сложения чисел 100 тысяч раз. В терминал прилетело 101006 сообщений.

Почему так много?

Во внутренних механизмах CPython каждое целое число представлено объектом PyLongObject в куче. И маленькие тоже.

Большинство VM используют tagged pointers, чтобы обойтись без лишних аллокаций. Даже Smalltalk в 80-х уже умел это. Python же идёт по тяжёлому пути: каждая аллокация тормозит работу, а редкий случай больших чисел ухудшает производительность самого частого кейса — простых интов.

Допущение: в тесте использовался print, который тоже может порождать новые ints. Разработчик убрал print. Количество аллокаций резко снизилось.

Куда делись остальные ~100k?

Смотрим функцию сложения ints. Если оба операнда меньше 2^30, их значения просто достаются и складываются напрямую. Тип stwodigits так и называется потому, что PyLongObject хранит число в основании 2^30 - каждый элемент массива хранит такой разряд.

Дальше вызывается _PyLong_FromSTwoDigits. В зависимости от величины числа - три пути.

Для маленьких чисел есть оптимизация: готовый статический массив маленьких PyLongObject, без аллокаций в куче. Просто возвращается указатель.

Для средних значений подключается другая функция. И вот что важно:

long_alloc тут не используется

Сначала пытается взять объект из freelist

Если нет свободных = создаёт новый

Freelist - типичная техника для переиспользования освобождённых объектов, чтобы лишний раз не трогать аллокатор.

В long_dealloc объект аккуратно возвращается в этот список.

Разработчик перенёс отладочный вывод в _PyLong_FromMedium: стало видно, что приличная часть объектов переиспользуется.

Но даже так накладные расходы огромные. На уровне процессора сложение двух int - одна инструкция ADD, исполняемая за один такт. В Python же вокруг неё целый аттракцион.

Плюс заметно отсутствие довольно старых оптимизаций, известных индустрии десятки лет.

Хороший пример того, что возможность контролировать аллокации позволяет строить специализированные аллокаторы и избавляться от мусора по пути.

И именно такие вещи делают языки вроде Zig привлекательными для разработчиков.

Подробнее с кодом: тык

👉 @PythonPortal