Интересный формат подачи материала, признаюсь, когда только начинал смотреть самое первое видео, подумал, что будет какая-то нудятина. А нет! Все оказалось вполне интересно, профессионально и что самое главное, понятно. Спасибо автор🤝, жду материал про garbage collector.
19:55 - это потому что garbage collector не отработал еще и python видит что уже такой объект в памяти есть, точнее еще есть и линкует на него? + не совсем непонятен момент что a = 257, b = 257 имеют один и тот же адрес в памяти. А в случае с enumerate разные свыше 256. А так спасибо за видео! Как всегда топ.
Тут такой принцип будет, применим и к семплу, и к числам 257 и т. д. - есть ситуации когда некоторые объекты будут иметь одинаковый адрес в памяти одномоментно, и тогда это один и тот же объект (любое число до 256 включительно), а есть ситуации, когда по определённому адресу лежал объект, но потом был удалён, и на его место встал другой объект, ретроспективно они меют одинаковые адреса тоже, но объекты разные. То есть a=257 и b=257 могут попасть в один и тот же адрес по очереди, если а было создано и удалено буквально сразу же перед созданием b. Объекты разные, но каждый свою жизнь провёл в одном и том же блоке памяти. Помним тут ещё о том, что у нас есть фиксированный размер блоков в памяти, поэтому такой принцип будет работать только для объектов одного размера.
конечно, дело в том, что строки интернируются до выполнения кода, в моём примере s, s1 и s2 уже на этапе трансляции в памяти начинают ссылаться на один и тот же объект, но интерпретатор заранее не может знать, что именно введёт пользователь, поэтому и проинтернировать это значение он не может (в некоторых языках интернирование выполняется именно во время работы программы, и там все одинаковые строки в любой момент времени будут храниться в виде одного экземпляра, но в Python реализована более простая версия, которая не тормозит выполнение)
11:53 - Озвучиваете что выражение с конкатенацией строки вычисляется в момент интерпретации. Мб какое-то расхождение в терминологии у нас. Интерпретация = компиляция в байт-код? Я почему-то интерпретировал :) этот термин как момент выполнения
Я бы сказал, что зависит от того, как мы понимаем компиляцию и интепретацию. Если мы считаем, что сначала код компилируется в байт-код, а потом выполняется интерпретатором, то да, вы абсолютно правы, я - нет. Я же привык к немного другой терминологии, что код интерпретируется в байт-код, а потом подаётся на выполнение в PVM, которая в целом тоже вляет ся частью интерпретатора. И для многих других языков программирования характерна такая же терминология, интерпретатор переводит в байт-код, какая-то среда этот код выполняет, компилятор страются не упоминать вообще, чтобы подчеркнуть разницу между подходами к выполнению. Допускаю, что терминология не самая точная, но опять-таки, тут многое зависит от того, что мы считаем интерпретатором, а что компилятором. В контексте же видео важно то, когда определённые события происходят, до выполнения кода, или во время. Сорри, что много текста накидал, если я в чём-то радикально не прав - смело пишите мне ответ, мне важно разобраться в вопросе, а не доказать свою правоту.
python: все одинаковые объекты- это один объект. rust: а на один объект 10 раз ссылаться нельзя. либо копируем, либо не мутируем. меньше вероятность состояния гонки при овердохренапоточном программировании.
все языки проектируются с какими-то целями, rust приближен к функциональным языкам сильнее, чем python, поэтому для него состояние объекта имеет более высокий приоритет, и это хорошо, это важный и нужный механизм защиты данных python с другой стороны плевать на состояние объекта, и это тоже хорошо, мы получаем больше гибкости и больше экономии памяти в конечном итоге выбор инструмента зависит от задачи и личных предпочтений, нет абсолютно плохих языков, точно так же как и нет универсального решения на все случаи жизни
Пока что mojo похож на хороший бизнесс-план по переизобретению среды для python) Он по сути переиспользует CPython, но достраивает много нового вокруг, идея крутая, но сам python от этого никуда не денется. Пишу так, не потому что python мой любимый язык или что-то такое, а просто опираясь на опыт, чтобы заменить один язык другим нужны годы принятия его программистами и компаниями, старты новых проектов, прекращение поддержки существующих решений на "устаревшем" языке и т. д. Учитывая текущую популярность python, процесс "замены" может занять десятилетие, а не "когда его релизнут". Плюс у нас есть характерный пример TypeScript, хороший язык, который построен на фундаменте JavaScript, прекрасно существуют оба, никто никого не заменил. Авторы mojo упоминают ещё swift, который по-сути язык ровно одной экосистемы, и опять-таки C заменить не смог, но нашёл свою нишу.
Окей, после гугления убедился что в документации питона числа диапазоном от -5 до 256 кэшируются. Интересно, почему именно от -5, а не от -256 например.
@@pythonclinicинтересно, почему кешируются цифры для всех стандартно? Можно ли анализировать код программы и его оптимизировать, кешируя только то, что нужно данной программе. Никогда не понимал питонячье управление памятью.
Соглашусь, можно сделать более таргетированный подход, но тогда мы лишимся части гибкости и автоматизации, а это не pythonic way) На самом деле я и сам не то чтобы представляю, почему именно такой набор цифр, а не шире, и не уже, и насколько много выйгрыша это даёт в конечном итоге. В документации везде ссылаются на какую-то "статистику")
Я нашел самое свежее видео на этом канале для того что бы сказать: Автор просто милашка :3
спасибо, мне очень приятно😊
Интересный формат подачи материала, признаюсь, когда только начинал смотреть самое первое видео, подумал, что будет какая-то нудятина. А нет! Все оказалось вполне интересно, профессионально и что самое главное, понятно. Спасибо автор🤝, жду материал про garbage collector.
спасибо за отзыв, видео о сборке мусора будет в следующий вторник)
Спасибо за контент. Всё это можно узнать и из документации, но смотреть ваши видео проще и интересней.
спасибо за отзыв)
19:55 - это потому что garbage collector не отработал еще и python видит что уже такой объект в памяти есть, точнее еще есть и линкует на него?
+ не совсем непонятен момент что a = 257, b = 257 имеют один и тот же адрес в памяти. А в случае с enumerate разные свыше 256.
А так спасибо за видео! Как всегда топ.
Тут такой принцип будет, применим и к семплу, и к числам 257 и т. д. - есть ситуации когда некоторые объекты будут иметь одинаковый адрес в памяти одномоментно, и тогда это один и тот же объект (любое число до 256 включительно), а есть ситуации, когда по определённому адресу лежал объект, но потом был удалён, и на его место встал другой объект, ретроспективно они меют одинаковые адреса тоже, но объекты разные. То есть a=257 и b=257 могут попасть в один и тот же адрес по очереди, если а было создано и удалено буквально сразу же перед созданием b. Объекты разные, но каждый свою жизнь провёл в одном и том же блоке памяти. Помним тут ещё о том, что у нас есть фиксированный размер блоков в памяти, поэтому такой принцип будет работать только для объектов одного размера.
Спасибо за видео, в конце про кортежи все же для меня было сложно. Можете, пожалуйста, создать видео по кэшированию в пайтон
внесу в список
Не до конца понял почему с инпута создается новая ячейка в памяти, могли бы еще раз тут объяснить? Спасибо!
конечно, дело в том, что строки интернируются до выполнения кода, в моём примере s, s1 и s2 уже на этапе трансляции в памяти начинают ссылаться на один и тот же объект, но интерпретатор заранее не может знать, что именно введёт пользователь, поэтому и проинтернировать это значение он не может
(в некоторых языках интернирование выполняется именно во время работы программы, и там все одинаковые строки в любой момент времени будут храниться в виде одного экземпляра, но в Python реализована более простая версия, которая не тормозит выполнение)
@@pythonclinic спасибо большое! Никита, у вас все получится! продолжайте в том же духе!
спасибо!)
11:53 - Озвучиваете что выражение с конкатенацией строки вычисляется в момент интерпретации. Мб какое-то расхождение в терминологии у нас.
Интерпретация = компиляция в байт-код? Я почему-то интерпретировал :) этот термин как момент выполнения
да, всё верно, конкатенация строк из литералов происходит в момент интерпритации, то есть ещё до выполнения, потому что значение уже можно вычислить
Автор называет компиляцию интерпретацией. Что неверно
@@pythonclinic Интерпретация - это выполнение. То, что вы называете интерпретацией - компиляция
Я бы сказал, что зависит от того, как мы понимаем компиляцию и интепретацию. Если мы считаем, что сначала код компилируется в байт-код, а потом выполняется интерпретатором, то да, вы абсолютно правы, я - нет. Я же привык к немного другой терминологии, что код интерпретируется в байт-код, а потом подаётся на выполнение в PVM, которая в целом тоже вляет ся частью интерпретатора. И для многих других языков программирования характерна такая же терминология, интерпретатор переводит в байт-код, какая-то среда этот код выполняет, компилятор страются не упоминать вообще, чтобы подчеркнуть разницу между подходами к выполнению. Допускаю, что терминология не самая точная, но опять-таки, тут многое зависит от того, что мы считаем интерпретатором, а что компилятором. В контексте же видео важно то, когда определённые события происходят, до выполнения кода, или во время.
Сорри, что много текста накидал, если я в чём-то радикально не прав - смело пишите мне ответ, мне важно разобраться в вопросе, а не доказать свою правоту.
@@pythonclinic Было бы здорово раскрыть эту тему подробней в одном из следующих видео, или серии следующих видео.
python: все одинаковые объекты- это один объект.
rust: а на один объект 10 раз ссылаться нельзя. либо копируем, либо не мутируем. меньше вероятность состояния гонки при овердохренапоточном программировании.
все языки проектируются с какими-то целями, rust приближен к функциональным языкам сильнее, чем python, поэтому для него состояние объекта имеет более высокий приоритет, и это хорошо, это важный и нужный механизм защиты данных
python с другой стороны плевать на состояние объекта, и это тоже хорошо, мы получаем больше гибкости и больше экономии памяти
в конечном итоге выбор инструмента зависит от задачи и личных предпочтений, нет абсолютно плохих языков, точно так же как и нет универсального решения на все случаи жизни
а никто не пробовал язык mojo? считаю что когда его релизнут, он заменит стандартный python.
Пока что mojo похож на хороший бизнесс-план по переизобретению среды для python) Он по сути переиспользует CPython, но достраивает много нового вокруг, идея крутая, но сам python от этого никуда не денется. Пишу так, не потому что python мой любимый язык или что-то такое, а просто опираясь на опыт, чтобы заменить один язык другим нужны годы принятия его программистами и компаниями, старты новых проектов, прекращение поддержки существующих решений на "устаревшем" языке и т. д. Учитывая текущую популярность python, процесс "замены" может занять десятилетие, а не "когда его релизнут". Плюс у нас есть характерный пример TypeScript, хороший язык, который построен на фундаменте JavaScript, прекрасно существуют оба, никто никого не заменил. Авторы mojo упоминают ещё swift, который по-сути язык ровно одной экосистемы, и опять-таки C заменить не смог, но нашёл свою нишу.
Окей, после гугления убедился что в документации питона числа диапазоном от -5 до 256 кэшируются. Интересно, почему именно от -5, а не от -256 например.
Насколько я понимаю, границы были выбраны на основе статистики использования объектов
@@pythonclinicинтересно, почему кешируются цифры для всех стандартно? Можно ли анализировать код программы и его оптимизировать, кешируя только то, что нужно данной программе. Никогда не понимал питонячье управление памятью.
Соглашусь, можно сделать более таргетированный подход, но тогда мы лишимся части гибкости и автоматизации, а это не pythonic way) На самом деле я и сам не то чтобы представляю, почему именно такой набор цифр, а не шире, и не уже, и насколько много выйгрыша это даёт в конечном итоге. В документации везде ссылаются на какую-то "статистику")