Forwarded from Pattern Guru. Шаблоны проектирования. Архитектура ПО
Идея поведенческого паттерна
Итератор (англ. Iterator) состоит в том, чтобы вынести поведение обхода коллекции в отдельный объект. Таким образом, если вам понадобится изменить или добавить новый способ обхода, вы сможете это сделать, не затрагивая код самой коллекции.
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Pavel Zloi
Пару часов назад пришло в личку такое вот сообщение, ну чтож, постараюсь изложить мои мысли.
Если кратко про основной вопрос, то прежде всего стоит уточнить, что есть ИИ-агент с моей точки зрения.
Частенько говоря об ИИ-агентах, возникает путаница, потому что разные люди вкладывают в этот термин разный смысл. В упрощённом виде ИИ-агент есть программа-помощник, которая умеет не только отвечать на вопросы, но и выполнять некие полезные действия.
Введение
Классический агент состоит из трёх частей:
- большая языковая модель (llm) — модель, которая принимает запросы пользователя и формулирует ответы.
- инструкция (prompt) — некий набор правил, которые задают агенту его поведение и роль.
- инструменты (tools) — внешние сервисы и функции, которыми агент может пользоваться и связываться с внешним миром, например искать информацию, делать расчёты, заказывать товары, писать код и так далее.
То есть, с моей скромной точки зрения, ИИ-агент — это не просто абстрактный чат-бот, а скорее связка: модель + инструкция + инструменты.
Классификация
Агенты можно условно разделить на две группы:
1. По количеству решаемых задач:
1.1. узкоспециализированные - делают что-то одно, но хорошо (например, агент для заполнения документов или поиска вакансий).
1.2. многофункциональные - способны решать разные задачи, пусть и не всегда хорошо, переключаясь между ролями (например, калькулятор + планировщик + переводчик).
2. По степени автономности:
2.1. ручные - выполняют запросы пошагово и только когда их просят.
2.2. автономные - это такие системы, которые могут сами планировать цепочку шагов и действовать без постоянного вмешательства человека (например, найти рынок для продукта, собрать данные и подготовить презентацию).
В принципе, сюда ещё можно добавить некоторые другие группы — навроде открытости языковых моделей, архитектуры реализации, способа взаимодействия с пользователем и так далее, но, полагаю, это слегка выходит за рамки.
Маркетплейc AI агентов
Но вернёмся к вопросу про создание маркетплейса ИИ-агентов в России. Итак, объяснив, что я имею в виду, когда говорю "ИИ-агент", попытаюсь ответить на поставленный вопрос. С моей точки зрения, в текущих реалиях появление подобного маркетплейса — вполне ожидаемое событие.
Но возникает ряд каверзных вопросов:
1. Какую проблему будет решать данный маркетплейс и как её решают пользователи сейчас без него?
2. Кто целевая аудитория маркетплейса? Физики или юрики?
3. Кто будет заниматься разработкой проекта подобного уровня?
4. Как масштабировать данный проект? Поставщики моделей? Поставщики инструментов?
и самое главное...
5. Как подобный проект будет зарабатывать? На подписках, решениях "под ключ" или как-то ещё?
Если порефлексировать и честно ответить на все перечисленные вопросы, то можно прийти к мысли о том, что:
Проект подобного масштаба в долгосрочной перспективе потянуть смогут лишь крупные поставщики нейросетевых решений, предоставляющие доступ к своим моделям через API. Но, как несложно догадаться, крупные отечественные игроки в основном ориентированы на собственные экосистемы и корпоративный сектор. Это значит, что маркетплейс в привычном для нас виде (а-ля витрина для всех) у них вряд ли окажется в приоритете.
С другой стороны, университеты, исследовательские центры, некоммерческие организации и независимые команды тоже могли бы сыграть в эту игру, но без системной поддержки государства или альянса нескольких технологических компаний, как мне кажется, может не хватить ресурсов.
Завершение
Поэтому идея маркетплейса ИИ-агентов в России кажется логичной и востребованной, но реализация, как мне кажется, будет зависеть не столько от технических возможностей (хорошие нейросети и продвинутые инструменты для агентов уже есть), сколько от организационной воли и готовности инвестировать в экосистему.
Если кратко про основной вопрос, то прежде всего стоит уточнить, что есть ИИ-агент с моей точки зрения.
Частенько говоря об ИИ-агентах, возникает путаница, потому что разные люди вкладывают в этот термин разный смысл. В упрощённом виде ИИ-агент есть программа-помощник, которая умеет не только отвечать на вопросы, но и выполнять некие полезные действия.
Введение
Классический агент состоит из трёх частей:
- большая языковая модель (llm) — модель, которая принимает запросы пользователя и формулирует ответы.
- инструкция (prompt) — некий набор правил, которые задают агенту его поведение и роль.
- инструменты (tools) — внешние сервисы и функции, которыми агент может пользоваться и связываться с внешним миром, например искать информацию, делать расчёты, заказывать товары, писать код и так далее.
То есть, с моей скромной точки зрения, ИИ-агент — это не просто абстрактный чат-бот, а скорее связка: модель + инструкция + инструменты.
Классификация
Агенты можно условно разделить на две группы:
1. По количеству решаемых задач:
1.1. узкоспециализированные - делают что-то одно, но хорошо (например, агент для заполнения документов или поиска вакансий).
1.2. многофункциональные - способны решать разные задачи, пусть и не всегда хорошо, переключаясь между ролями (например, калькулятор + планировщик + переводчик).
2. По степени автономности:
2.1. ручные - выполняют запросы пошагово и только когда их просят.
2.2. автономные - это такие системы, которые могут сами планировать цепочку шагов и действовать без постоянного вмешательства человека (например, найти рынок для продукта, собрать данные и подготовить презентацию).
В принципе, сюда ещё можно добавить некоторые другие группы — навроде открытости языковых моделей, архитектуры реализации, способа взаимодействия с пользователем и так далее, но, полагаю, это слегка выходит за рамки.
Маркетплейc AI агентов
Но вернёмся к вопросу про создание маркетплейса ИИ-агентов в России. Итак, объяснив, что я имею в виду, когда говорю "ИИ-агент", попытаюсь ответить на поставленный вопрос. С моей точки зрения, в текущих реалиях появление подобного маркетплейса — вполне ожидаемое событие.
Но возникает ряд каверзных вопросов:
1. Какую проблему будет решать данный маркетплейс и как её решают пользователи сейчас без него?
2. Кто целевая аудитория маркетплейса? Физики или юрики?
3. Кто будет заниматься разработкой проекта подобного уровня?
4. Как масштабировать данный проект? Поставщики моделей? Поставщики инструментов?
и самое главное...
5. Как подобный проект будет зарабатывать? На подписках, решениях "под ключ" или как-то ещё?
Если порефлексировать и честно ответить на все перечисленные вопросы, то можно прийти к мысли о том, что:
Проект подобного масштаба в долгосрочной перспективе потянуть смогут лишь крупные поставщики нейросетевых решений, предоставляющие доступ к своим моделям через API. Но, как несложно догадаться, крупные отечественные игроки в основном ориентированы на собственные экосистемы и корпоративный сектор. Это значит, что маркетплейс в привычном для нас виде (а-ля витрина для всех) у них вряд ли окажется в приоритете.
С другой стороны, университеты, исследовательские центры, некоммерческие организации и независимые команды тоже могли бы сыграть в эту игру, но без системной поддержки государства или альянса нескольких технологических компаний, как мне кажется, может не хватить ресурсов.
Завершение
Поэтому идея маркетплейса ИИ-агентов в России кажется логичной и востребованной, но реализация, как мне кажется, будет зависеть не столько от технических возможностей (хорошие нейросети и продвинутые инструменты для агентов уже есть), сколько от организационной воли и готовности инвестировать в экосистему.
Forwarded from Ebout Data Science | Дима Савелко
Уничтожение MLSD по созданию чат-бота Постановка задачи
Ситуация: Нужен чат-бот-юрист, который сможет первично консультировать клиентов по законам. Например, кто-то дунул газика и теперь тебе нужно найти все статьи и законы, которые связаны с котиками. Пример: «Браток, как защититься от того, что жёстко дал газу в башню и теперь меня ищут менты?» → бот ищет статьи и выдает нормальный структурированный ответ с источниками, которые помогут защититься от легавых
Ограничения:
Метрики
Бизнес-метрики - метрики, которые важны в первую очередь бизнесу
на прием или переход по ссылке — через чатик с ботом
Онлайн-метрики - метрики, которые будем мерить при A/B тестах
Оффлайн-метрики - метрики, которые мы считаем прям во время разработки модели
Но у нас нет разметки, как получить offline-метрики без разметки? Делаем небольшую ручную разметку через копирайтеров или на основе типичных запросов клиентов, а потом делаем синту через GPT на основе уже размеченных данных. Так можно наиболее точно и эффективно разметит инфу, чтобы чел нашёл абсолютно всё про хапку
Данные:
Индексация и векторизация:
Retrieve pipeline — как ищем чанки по газикам
Формирование ответа с помощью LLM
Проблемы:
Итоговый пайплайн:
Запрос → Предобработка → Поиск чанков → Промпт → Ответ → Пользователь.
Это был baseline, который дальше можно улучшать и улучшать, у которого есть свои проблемы. И их в одном посте я точно описать не смогу
Что можно улучшить
- Провести тесты с разными ЛЛМ-ками и энкодерами
- Проработать агентную систему, которая будет улучшать качество и безопасность системы. К примеру, query routing - классифицировать запрос: материальное право / процесс / процедурка / «как оформить»; под каждый — свой шаблон ответа и k.
- Сделать tool call при необходимости
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Artem Khakimov
Слушай, имхо на 100% не согласен с векторной бд - у тебя в любой задаче где требуется жесть какая защита от галлюцинаций ( как например юридические документы) нужно строить графовые бд. Ну или ты просто не написал как будешь с галюнами бороться, потому что это основная проблема тут
Forwarded from GK trips (George Korepanov)
Небольшое пост-расследование про LLM-модели 🤖
Немного контекста. Мы с моим другом Каримом часто разгоняем мысль, что мы живём в уникальное время и можем наблюдать беспрецедентное соревнование между компаниями, обучающими LLM-модели. Обычно компании соревнуются неявно, и качество их продуктов никто напрямую не оценивает (например, нет объективных метрик, показывающих, чей поиск лучше — Google, Яндекса или Bing).
А в LLM-мире есть конкретные бенчмарки, и при релизе очередной модели каждая компания публикует результаты по ним. То есть мы буквально наблюдаем за гонкой, как на скачках 🏇 (только ставки в миллионы раз выше).
Среди прочих, есть такой бенчмарк — SWE-bench-verified (https://openai.com/index/introducing-swe-bench-verified/), который проверяет, как модели в агентном режиме способны фиксить баги в реальных больших open-source репозиториях. Разумеется, и Google, и Anthropic, и OpenAI публикуют скоры своих моделей на SWE-bench. На данный момент фигурируют такие числа:
OpenAI GPT-5: 74.9%
Anthropic Opus 4.1: 74.5% 📊
Казалось бы, всё очевидно и понятно — кто лучше, кто хуже. Но твиттер кипит: OpenAI проверяют свою модель не на всех 500 задачах, а на 477! И значит, «реальный» результат GPT-5 — 71%!
Это отчасти правда: OpenAI действительно не проверяли модель на всём наборе. И это действительно обесценивает сравнение, потому что мы сопоставляем тёплое с мягким, ведь мы не знаем, как GPT-5 повела бы себя на 23 непокрытых задачах.
Я решил разобраться в вопросе и копнуть глубже, чтобы понять, какие метрики были бы «справедливыми». К счастью, мне не пришлось прогонять бенчмарк руками: есть компания Epoch.AI, которая независимо прогоняет SWE-bench-verified на всех 500 задачах и публикует скоры для каждой модели. По её замерам GPT-5 набирает 59%, а Opus 4.1 — 63%. Помимо итоговых метрик Epoch.AI выложила логи запусков каждой модели на каждой задаче, и можно глазами отследить, что происходило. Разница с официальными числами некислая, к тому же Opus вырвался вперед. Тут явно что-то нечисто, поэтому я спарсил данные с их сайта и сделал небольшой анализ.
Немного контекста. Мы с моим другом Каримом часто разгоняем мысль, что мы живём в уникальное время и можем наблюдать беспрецедентное соревнование между компаниями, обучающими LLM-модели. Обычно компании соревнуются неявно, и качество их продуктов никто напрямую не оценивает (например, нет объективных метрик, показывающих, чей поиск лучше — Google, Яндекса или Bing).
А в LLM-мире есть конкретные бенчмарки, и при релизе очередной модели каждая компания публикует результаты по ним. То есть мы буквально наблюдаем за гонкой, как на скачках 🏇 (только ставки в миллионы раз выше).
Среди прочих, есть такой бенчмарк — SWE-bench-verified (https://openai.com/index/introducing-swe-bench-verified/), который проверяет, как модели в агентном режиме способны фиксить баги в реальных больших open-source репозиториях. Разумеется, и Google, и Anthropic, и OpenAI публикуют скоры своих моделей на SWE-bench. На данный момент фигурируют такие числа:
OpenAI GPT-5: 74.9%
Anthropic Opus 4.1: 74.5% 📊
Казалось бы, всё очевидно и понятно — кто лучше, кто хуже. Но твиттер кипит: OpenAI проверяют свою модель не на всех 500 задачах, а на 477! И значит, «реальный» результат GPT-5 — 71%!
Это отчасти правда: OpenAI действительно не проверяли модель на всём наборе. И это действительно обесценивает сравнение, потому что мы сопоставляем тёплое с мягким, ведь мы не знаем, как GPT-5 повела бы себя на 23 непокрытых задачах.
Я решил разобраться в вопросе и копнуть глубже, чтобы понять, какие метрики были бы «справедливыми». К счастью, мне не пришлось прогонять бенчмарк руками: есть компания Epoch.AI, которая независимо прогоняет SWE-bench-verified на всех 500 задачах и публикует скоры для каждой модели. По её замерам GPT-5 набирает 59%, а Opus 4.1 — 63%. Помимо итоговых метрик Epoch.AI выложила логи запусков каждой модели на каждой задаче, и можно глазами отследить, что происходило. Разница с официальными числами некислая, к тому же Opus вырвался вперед. Тут явно что-то нечисто, поэтому я спарсил данные с их сайта и сделал небольшой анализ.
Forwarded from GK trips (George Korepanov)
Загибайте пальцы — сколько дичи нашлось 🕵️♂️:
1. Лимит в 1M токенов на задачу. Epoch.AI для каждой модели установила порог: как только модель потратила миллион токенов, её останавливают и имеющиеся в коде изменения прогоняют через автотесты. То есть даже если модель двигалась в верном направлении, в какой-то момент у неё забирают работу (как тетрадку на контрольной после звонка 😅) и проверяют то, что она успела сделать. В итоге Opus не успел закончить работу примерно в 80% задач, а GPT-5 — в ~40%.
Пример — задача
2. Задача
3. Задача
Другой пример: scikit-learn__scikit-learn-14710 — GPT-5 задачу решил(!), но она не засчиталась, т.к. тест просто завис.
4.
5.
6.
1. Лимит в 1M токенов на задачу. Epoch.AI для каждой модели установила порог: как только модель потратила миллион токенов, её останавливают и имеющиеся в коде изменения прогоняют через автотесты. То есть даже если модель двигалась в верном направлении, в какой-то момент у неё забирают работу (как тетрадку на контрольной после звонка 😅) и проверяют то, что она успела сделать. В итоге Opus не успел закончить работу примерно в 80% задач, а GPT-5 — в ~40%.
Пример — задача
astropy__astropy-13977: GPT-5 просто не успела внести нужные правки. Почему так? В SWE-bench используются кривоватые инструменты редактирования и чтения кода, которые часто приходится вызывать несколько раз, прежде чем они сработают.2. Задача
astropy__astropy-13033. GPT-5 справилась с требованием задачи и смогла сделать так, чтобы при некорректных действиях пользователя код падал с определённой ошибкой. Но тесты бенчмарка проверяют, что сообщение об ошибке содержит конкретный текст, а GPT-5 использовала другую формулировку. Селяви, задача не засчитана. Аналогично в sympy__sympy-13852: тесты проверяют исправление не только того бага, который описан в исходном issue, но и нескольких других, и в результате модели тоже получают незачёт.3. Задача
sympy__sympy-13091. Opus задачу не решил: посадил новый баг, из-за которого в одном из тестов случилось переполнение стека (бесконечная рекурсия). Но задачка засчиталась 🙂 Другой пример: scikit-learn__scikit-learn-14710 — GPT-5 задачу решил(!), но она не засчиталась, т.к. тест просто завис.
4.
django__django-15127. Opus очень грамотно предложил три варианта решения и выбрал первый. Однако тесты проверяли, что решение будет строго определённым. Не угадал — не засчитали. Похоже на преподавателя, который требует от студента доказательство «как на лекции».5.
scikit-learn__scikit-learn-14629. Здесь я уже смеялся вслух. С одной стороны, кейс похож на предыдущий: в этот раз GPT-5 избрала определённый метод решения, а тесты ожидали другой, конкретный способ — такой, какой был у автора багфикса. Мне стало интересно, как же тогда эту задачу решил Opus. Оказалось, он написал код, символ-в-символ совпадающий с тем, который написали люди в 2019 году при закрытии бага (https://github.com/scikit-learn/scikit-learn/issues/14615). Неудивительно: это open-source код, и все LLM-модели на нём обучались. Спекулирую, что Opus существенно «крупнее», чем GPT-5, и просто лучше «помнит» исходный код библиотеки. В целом бенчмарк, в котором все (!) задачи взяты из open-source библиотек, на которых обучались все без исключения модели, — это не очень хорошая идея 😅6.
django__django-16642. Обе модели решили, но GPT-5 использовала современное название MIME-типа — application/brotli, а Opus — устаревшее application/x-brotli. Знаете, кто победил? Конечно, Opus! 🤷♂️Forwarded from GK trips (George Korepanov)
Ну вы уже поняли тенденцию, да?
Я изучил ещё десяток задач, где Opus зачли решение, а GPT-5 — нет. Они почти все сводятся к одной вещи: Opus заранее пишет тесты к своим правкам, а GPT-5 — нет. В результате Opus вносит правки до посинения, пока все тесты не пройдут (иногда упираясь в лимит, настрочив сотни строк кода). GPT-5 же идёт, засучивает рукава, сразу делает фикс и сабмитит ответ. То есть на всех этих задачах банальная инструкция в промпте — «сначала напиши хороший тест, который покрывает разные случаи, убедись, что он запускается и ловит все ошибки из issue; затем вноси правки в код до тех пор, пока твои тесты и все существующие не проходят» — перетасовала бы результаты с ног на голову.
И теперь на десерт: знаете, сколько среди 500 задач таких, на которых результаты Opus и GPT-5 отличаются, и при этом GPT-5 не упёрся в лимит по токенам? 36. Тридцать шесть, Карл! Вся «точность» датасета, которая определяет, какая модель лучше, а какая хуже, оказалась заперта внутри 36 задач — это 7% набора. Все остальные задачи либо настолько простые, что их решают обе модели, либо настолько корявые/специфичные, что их не решает никто.
Какие выводы? Проверять знания — крайне сложная задача. Точно так же, как ЕГЭ не измеряет глубину понимания, как собеседование не гарантирует успешность в работе, как Канеман в израильской армии не смог по психотестам определять пригодность к службе, так и бенчмарки являются сомнительным способом измерять «интеллект» модели. Те, кто хоть раз обучал сложные ML-модели, это знают. Но то, что бенчмарк, на который опираются крупные компании, продавая модели пользователям и инвесторам, окажется настолько мусорным, — такого я не ожидал 🤯. Честно, я не уверен, что встретил в нём хотя бы одну задачу, где реально видно качественное превосходство одной модели над другой.
tl;dr
Не смотрите на SWE-bench-verified. Он ничего не проверяет и не говорит, какая модель лучше, а какая хуже. ✅❌
Я изучил ещё десяток задач, где Opus зачли решение, а GPT-5 — нет. Они почти все сводятся к одной вещи: Opus заранее пишет тесты к своим правкам, а GPT-5 — нет. В результате Opus вносит правки до посинения, пока все тесты не пройдут (иногда упираясь в лимит, настрочив сотни строк кода). GPT-5 же идёт, засучивает рукава, сразу делает фикс и сабмитит ответ. То есть на всех этих задачах банальная инструкция в промпте — «сначала напиши хороший тест, который покрывает разные случаи, убедись, что он запускается и ловит все ошибки из issue; затем вноси правки в код до тех пор, пока твои тесты и все существующие не проходят» — перетасовала бы результаты с ног на голову.
И теперь на десерт: знаете, сколько среди 500 задач таких, на которых результаты Opus и GPT-5 отличаются, и при этом GPT-5 не упёрся в лимит по токенам? 36. Тридцать шесть, Карл! Вся «точность» датасета, которая определяет, какая модель лучше, а какая хуже, оказалась заперта внутри 36 задач — это 7% набора. Все остальные задачи либо настолько простые, что их решают обе модели, либо настолько корявые/специфичные, что их не решает никто.
Какие выводы? Проверять знания — крайне сложная задача. Точно так же, как ЕГЭ не измеряет глубину понимания, как собеседование не гарантирует успешность в работе, как Канеман в израильской армии не смог по психотестам определять пригодность к службе, так и бенчмарки являются сомнительным способом измерять «интеллект» модели. Те, кто хоть раз обучал сложные ML-модели, это знают. Но то, что бенчмарк, на который опираются крупные компании, продавая модели пользователям и инвесторам, окажется настолько мусорным, — такого я не ожидал 🤯. Честно, я не уверен, что встретил в нём хотя бы одну задачу, где реально видно качественное превосходство одной модели над другой.
tl;dr
Не смотрите на SWE-bench-verified. Он ничего не проверяет и не говорит, какая модель лучше, а какая хуже. ✅❌
Forwarded from LLM под капотом
Я доделываю небольшую демку, которая показывает, как сделать планируюшего бизнес-ассистента с доступом к инструментам, на базе Schema-Guided Reasoning и недорогой модели.
Код я потом выложу в статье.
На скриншоте - пример запуска агента. Тут я попросил переделать последний инвойс Маску, там нужно сделать скидку в три раза больше, чем та, что была у Sama.
Вопрос. Как вы думаете, сколько строчек кода в этой демке?
Подсказка:
- Система не использует GPT-5. Модель под капотом даже не из TOP-20 моего SGR бенчмарка, ибо для такой простоты ничего мощного не нужно.
- Никаких сторонних фреймворков не используется. Tool Use тоже самописный (tools интегрированы с планировщиком и работают на одном-единственном SGR-промпте). Только openai и pydantic.
- Реализована простая in-memory CRM система с инвойсами, продуктами, памятью, отправкой писем.
Итак, сколько строчек кода может быть в такой демке? Каждая строчка не более 80 символов, и это не code golf, естественно.
Ваш, @llm_under_hood 🤗
PS: Того, кто укажет самое нереально маленькое число - попросим показать класс и написать самостоятельно))
Код я потом выложу в статье.
На скриншоте - пример запуска агента. Тут я попросил переделать последний инвойс Маску, там нужно сделать скидку в три раза больше, чем та, что была у Sama.
Вопрос. Как вы думаете, сколько строчек кода в этой демке?
Подсказка:
- Система не использует GPT-5. Модель под капотом даже не из TOP-20 моего SGR бенчмарка, ибо для такой простоты ничего мощного не нужно.
- Никаких сторонних фреймворков не используется. Tool Use тоже самописный (tools интегрированы с планировщиком и работают на одном-единственном SGR-промпте). Только openai и pydantic.
- Реализована простая in-memory CRM система с инвойсами, продуктами, памятью, отправкой писем.
Итак, сколько строчек кода может быть в такой демке? Каждая строчка не более 80 символов, и это не code golf, естественно.
Ваш, @llm_under_hood 🤗
PS: Того, кто укажет самое нереально маленькое число - попросим показать класс и написать самостоятельно))
Forwarded from Находки в опенсорсе
Три типа объектов в Питоне
В питоне часто любят обсуждать "мутабельные" и "иммутабельные" объекты, но крайне редко объясняют, в чем же на самом деле разница. Сегодня мы посмотрим на такое со стороны C.
PyObject
Все мы знаем, что в питоне все объект или
То есть: у нас есть только счетчик ссылок на объект и указатель на его тип. Первое меняется очень часто, если объект не immortal. Второе тоже можно менять в некоторых случаях:
Получается, что большинство объектов мутабельные уже на данном уровне.
Но, в целом есть три типа объектов, разные по уровню мутабельности:
1. Такие как
2. Такие как
3. Такие как
Отдельно нужно отметить, что пользовательские классы обычно еще более мутабельны, потому что их тип менять можно.
Но, вопрос в другом: а где вообще хранится размер объекта и его внутренности? Раз в
C-API
В C-API питона есть два полезных макроса: PyObject_HEAD для объектов фиксированного размера и PyObject_VAR_HEAD для объектов, которые могут менять размер.
Хотим поменять размер объекта? Увеличиваем
Итоговые объекты используют примерно такую логику:
То есть: на самом деле все объекты
- Имеют свой собственный тип:
- Имеют общую абстракцию для размерности:
- Имеют общую абстракцию для типа и счетчика ссылок:
Я сделал небольшой очень упрощенный пример. Там я показываю в том числе, как происходит каст одного типа поинтера в другой в C.
Итог
1.
2.
3.
Обсуждение: как вы думаете, как работает
| Поддержать | YouTube | GitHub | Чат |
В питоне часто любят обсуждать "мутабельные" и "иммутабельные" объекты, но крайне редко объясняют, в чем же на самом деле разница. Сегодня мы посмотрим на такое со стороны C.
PyObject
Все мы знаем, что в питоне все объект или
PyObject *, который упрощенно выглядит так (в FT сборке он посложнее):
struct _object {
Py_ssize_t ob_refcnt;
PyTypeObject *ob_type;
}
То есть: у нас есть только счетчик ссылок на объект и указатель на его тип. Первое меняется очень часто, если объект не immortal. Второе тоже можно менять в некоторых случаях:
>>> class A:
... __slots__ = ()
>>> class B:
... __slots__ = ()
>>> a = A()
>>> type(a)
<class '__main__.A'>
>>> a.__class__ = B
>>> type(a)
<class '__main__.B'>
Получается, что большинство объектов мутабельные уже на данном уровне.
Но, в целом есть три типа объектов, разные по уровню мутабельности:
1. Такие как
None: ob_refcnt не меняется (immortal), тип менять нельзя, ведь Py_TPFLAGS_IMMUTABLETYPE установлен (static type), размер неизменный 0 для всех потенциальных значений2. Такие как
int: ob_refcnt может меняться для больших чисел (маленькие инты - immortal), тип менять нельзя, размер нельзя менять, но он будет разный для разных чисел:
>>> sys.getsizeof(1)
28
>>> sys.getsizeof(10000000000000)
32
3. Такие как
list: ob_refcnt всегда меняется, тип менять нельзя, размер меняетсяОтдельно нужно отметить, что пользовательские классы обычно еще более мутабельны, потому что их тип менять можно.
Но, вопрос в другом: а где вообще хранится размер объекта и его внутренности? Раз в
PyObject ничего такого нет.C-API
В C-API питона есть два полезных макроса: PyObject_HEAD для объектов фиксированного размера и PyObject_VAR_HEAD для объектов, которые могут менять размер.
struct PyVarObject {
PyObject ob_base;
Py_ssize_t ob_size; /* Number of items in variable part */
};
#define PyObject_HEAD PyObject ob_base;
#define PyObject_VAR_HEAD PyVarObject ob_base;
Хотим поменять размер объекта? Увеличиваем
ob_size, аллоцируем новую память (если нужно) под новые объекты внутри.Итоговые объекты используют примерно такую логику:
typedef struct {
PyObject_VAR_HEAD
/* Vector of pointers to list elements. list[0] is ob_item[0], etc. */
PyObject **ob_item;
/* ob_item contains space for 'allocated' elements. The number
* currently in use is ob_size.
*/
Py_ssize_t allocated;
} PyListObject;
То есть: на самом деле все объекты
list (и многие другие) не просто PyObject, они:- Имеют свой собственный тип:
PyListObject- Имеют общую абстракцию для размерности:
PyVarObject- Имеют общую абстракцию для типа и счетчика ссылок:
PyObjectЯ сделал небольшой очень упрощенный пример. Там я показываю в том числе, как происходит каст одного типа поинтера в другой в C.
Итог
1.
None не имеет внутреннего состояния вообще (не использует ничего)2.
int может иметь разный размер, но не может изменяться, потому использует PyObject_HEAD (раньше был PyObject_VAR_HEAD, там сложная история):
typedef struct _PyLongValue {
uintptr_t lv_tag; /* Number of digits, sign and flags */
digit ob_digit[1];
} _PyLongValue;
struct _longobject {
PyObject_HEAD
_PyLongValue long_value;
};
3.
list может иметь разный размер и может изменятся, потому использует PyObject_VAR_HEAD, как я показывал вышеОбсуждение: как вы думаете, как работает
len() для list? | Поддержать | YouTube | GitHub | Чат |
Python documentation
Common Object Structures
There are a large number of structures which are used in the definition of object types for Python. This section describes these structures and how they are used. Base object types and macros: All ...