Дуже класно структуроване роз'яснення. Розумію, що підготовка відео займає багато часу, але таких відео треба більше і на всі можливі теми щодо пайтону😅 дякую❤
Відео про Rest API вже є на каналі ruclips.net/video/S0dlZ9DLqE0/видео.html Далі в продовження серії відео про ВЕБ планую відео про перенос Rest API викликів у Пайтон код.
@@python_decoded Дякую, я не уточнив, хотів би в майбутньому побачити серію відео про Flask, fastapi) Багатьом було би цікаво глянути, особливо зважаючи, що українською такого майже немає))
Гадаю саме за цією схемою пайтон перед виконанням важкої операції розраховує приблизну кількість пам'яті, щоб не покласти ОС. Наприклад обробити мільярд записів з БД у функції з return замість yield.
Складно прокоментувати, без конкретного прикладу перед очима, та фішка генератору в тому що в його локальній області видимості зазвичай знаходиться один обʼєкт або одна сторінка, та не усі одразу, яку генератор йелдить, замість того щоб збирати усі такі обʼєкти у колекцію, тобто тут спрацьовує принцип конвейера. і ніби як виходить що ми кожною новою сторінкою перезаписуємо попередню, тож нам не потрібно більше памʼяті аніж тої, щоб зберігати 1 - 2 сторінки, навіть якщо нам потрібно обробити мільярд записів. А покласти OC задопомогою пайтону не складно items = [ ] for i in range(10000000000): items.apend(10 ** i)
@@python_decoded Щодо генераторної функції, вона ж зберігає обєкт генератора в памяті після виконання. Цей обєкт зберігається в купі, і при наступному виклику повертається в стек? Чи він залишається в стеку до наступного виклику?
@@CreeperTeamMine гарне питання, при виклику генераторної функції, вона створює обʼєкт генератор, який тепер зберігається у хіпі, і усі його обʼєкти, створені підчас виконання тіла генератора (локальна область видимості) також зберігаються у хіпі. оскільки ми маємо синхронне виконання коду в одному треді, я так розумію підчас виконання тіла генератора створюється елемент стеку, туди вигружаються посилання на елементи хіпу, потім генератор ставиться на паузу його стан зберігається (усі локальні посилання), і сегмент памʼяті вивільняється із стеку. коли в тілі генератора ми доходимо до ключового слова return, нема більше сенсу зберігати локальну область видимості, і її можна прибрати. Це трохи здогадки з моєї сторони, адже C реалізацію генератору не читав, та думаю якось так воно і працює.
зібрав трохи пруфів: pywheel.com/generators-behind-the-scenes/ Функція використовує 'frame' object для створення елементу стеку Генератор використовує 'gi_frame'. Різниця в тому, що генератор при виконання інструкції YIELD_VALUE виконує призупинення генератору (FRAME_SUSPENDED), записує в gi_frame поточну позицію і прибирає gi_frame зі стеку, щоб наступний раз продовжити виконання з того місця на якому зупинився попередній раз. При виконанні інструкції RETURN_VALUE gi_frame знову таки прибирається зі стеку та разом з тим видаляється із генератора.
Інформативно корисно та зрозуміло. Дякую за відео!
Дуже класно структуроване роз'яснення. Розумію, що підготовка відео займає багато часу, але таких відео треба більше і на всі можливі теми щодо пайтону😅 дякую❤
дякую за підтримку
Щиро Вам дякую за такий класний контент
Дуже бажаю побачити відео про rest api
Відео про Rest API вже є на каналі
ruclips.net/video/S0dlZ9DLqE0/видео.html
Далі в продовження серії відео про ВЕБ планую відео про перенос Rest API викликів у Пайтон код.
@@python_decoded Дякую, я не уточнив, хотів би в майбутньому побачити серію відео про Flask, fastapi)
Багатьом було би цікаво глянути, особливо зважаючи, що українською такого майже немає))
@@BohdanHalunka потроху рухаємося в цьому напрямку
Гадаю саме за цією схемою пайтон перед виконанням важкої операції розраховує приблизну кількість пам'яті, щоб не покласти ОС. Наприклад обробити мільярд записів з БД у функції з return замість yield.
Складно прокоментувати, без конкретного прикладу перед очима,
та фішка генератору в тому що в його локальній області видимості зазвичай знаходиться один обʼєкт або одна сторінка, та не усі одразу,
яку генератор йелдить, замість того щоб збирати усі такі обʼєкти у колекцію, тобто тут спрацьовує принцип конвейера.
і ніби як виходить що ми кожною новою сторінкою перезаписуємо попередню, тож нам не потрібно більше памʼяті аніж тої, щоб зберігати 1 - 2 сторінки, навіть якщо нам потрібно обробити мільярд записів.
А покласти OC задопомогою пайтону не складно
items = [ ]
for i in range(10000000000):
items.apend(10 ** i)
@@python_decoded Щодо генераторної функції, вона ж зберігає обєкт генератора в памяті після виконання. Цей обєкт зберігається в купі, і при наступному виклику повертається в стек? Чи він залишається в стеку до наступного виклику?
@@CreeperTeamMine гарне питання,
при виклику генераторної функції, вона створює обʼєкт генератор, який тепер зберігається у хіпі, і усі його обʼєкти, створені підчас виконання тіла генератора (локальна область видимості) також зберігаються у хіпі.
оскільки ми маємо синхронне виконання коду в одному треді, я так розумію підчас виконання тіла генератора створюється елемент стеку, туди вигружаються посилання на елементи хіпу, потім генератор ставиться на паузу його стан зберігається (усі локальні посилання), і сегмент памʼяті вивільняється із стеку.
коли в тілі генератора ми доходимо до ключового слова return, нема більше сенсу зберігати локальну область видимості, і її можна прибрати.
Це трохи здогадки з моєї сторони, адже C реалізацію генератору не читав, та думаю якось так воно і працює.
зібрав трохи пруфів:
pywheel.com/generators-behind-the-scenes/
Функція використовує 'frame' object для створення елементу стеку
Генератор використовує 'gi_frame'.
Різниця в тому, що генератор при виконання інструкції YIELD_VALUE виконує призупинення генератору (FRAME_SUSPENDED), записує в gi_frame поточну позицію і прибирає gi_frame зі стеку, щоб наступний раз продовжити виконання з того місця на якому зупинився попередній раз.
При виконанні інструкції RETURN_VALUE gi_frame знову таки прибирається зі стеку та разом з тим видаляється із генератора.
@@python_decoded дякую за змістовну відповідь)