всё будет)

и оно таки будет на следующей неделе) спасибо)

thanks!

В опциях диаграмы включить Sketch

ох, интересные вопросы, попробую аккуратно ответить: 1) свечку не держал, но предположу, что такая архитектура придумана для гибкости работы со всеми объектами по ссылке, грубо говоря ко всем объектам применяются одинаковые стандарты подсчёта ссылок и отправления их в последний путь 2) в теории да, если он прям огромный 3) заданных значений нет, объекты в теории прям бесконечно большие, но есть такой момент, что изменяемые объекты меняться не могут, поэтому мы их размер один раз при создании вычисляем и на этом успокаиваемся, а изменяемые объекты это всегда наборы ссылок, которые в свою очередь могут ссылаться либо на неизменяемые (размер которых мы знаем), либо на изменяемые, которые тоже суть наборы ссылок и так до конца, пока по всем ссылкам мы не упрёмся либо в неизменяемые, либо в пустые объекты, и тогда для изменяемых объектов достаточно просто пройти по всем ссылкам и посчитать размер всего, что мы встретим на своём пути (но интерпретатор этого не делает вообще говоря, ему не нужно, потому что важно разложить в памяти именно неизменяемые объекты, и для них знать размер, а всякие списки это всего лишь оболочки пусть и со своей логикой хранения внутри, но всё равно там только ссылки в основном, их размер фиксирован и относительно мал)

Похожие концепции используются в большинстве языков с автоматическим управлением памятью, но они все различаются в деталях, иногда очень сильно, например, в C# тоже есть стэк и куча, но в обоих будут храниться прям живые объекты, а переменные будут существовать вообще отдельно

1. есть и untouched, но он не настолько интересен, freeblock позволяет переиспользовать "арендованную" память, это чаще всего важнее, чем использовать новую, и поэтому их учитывают отдельно, экономия на всём и всегда 2. соглашусь, что в теории такая операция возможна, но на практике она была бы досточно "дорогой" для самой os + не совсем понятно, в какой именно момент отдавать кусок неиспользованной арены обратно, нужно быть прям уверенным, что оно больше не понадобится, а это возможно только если программа завершена, но в этом случае всё отдадим и так 3. нет, по умолчанию нет, потому что предпологается, что обращение по ссылке происходит за постоянное время, но в некоторых ситуациях своего рода группировка реализуется специально, например для массивов numpy, а в некоторых она возникает сама (если объекты улетают в один пул)

@@pythonclinic спасибо за ответ! Насчёт константного доступа: в случае кэширования есть разница)

Спасибо за отличные вопросы, разбираемся: 1. Идея верная, размер блоков в пуле подстраивается под первый добавленный объект, но при этом размеры блоков заранее предопределены - 8, 16, 24, 32, 40, ... , 512 байт. Из этих размеров выбирается минимальный, в который влезет новый объект. 2. В таких случаях будет работать совершенно другой механизм выделения памяти, если объект не влезает в пул, и его нельзя разбить на части и как-то эти части связать, то pvm попытается спихнуть ответственность на операционную систему, которая конечно же справится с этой задачей, если у неё самой будет достаточно памяти "на руках". Это, очевидно, очень плохой сценарий, так как этот объект выпадает из стандартного флоу управления памятью, и приводит к дополнительной фрагментации памяти на уровне операционной системы.

@@pythonclinic Спасибо за подробный ответ.

процесс полностью автоматический, мы можем немного на него влиять через модуль gc (сборщик мусора), а ещё мы можем сделать некоторые выводы о работе с объектами в памяти, я расскажу об этом в дополнительных видео

экологично, потому что уже выделенная память переиспользуется

В настройках диаграммы нужно включить параметр sketch

не, не поделится, большинство объектов в пайтон относятся к сложно устроенным ссылочным типам данных, части которых не будут превышать лимит и они будут хранится в разных аренах

никаких секретов, это документация и исходный код Python)