Как стать автором
Поиск
Написать публикацию
Обновить

Комментарии 5

Интересная КДПВ - код одинаковый а знчки разные) Чему это должно нас научить?

Cпасибо тем, кто дочитал статью до конца. Буду признателен за конструктивную критику в комментариях

Долистал. Про эту функциональность у меня всёгда возникает вопрос а зачем мне это.

Я так ни разу send и не использовал для нормальных задач. Так поиграться сделать свою версию асинхронности на герераторах.

Это всё для кастомных низкоуровневых реализаций по большей части)
Старая добрая асинхронщина до asyncio была написана на генераторах, вот там это всё и годится.
Кому-то может надо писать какие-то адаптеры легаси библиотек к asyncio или наоборот и всё в таком духе.

Зачем мне это

Это как в метаклассах, "если вы не знаете зачем они вам нужны - они вам не нужны".

Генератор это всегда ленивость вычисления и, не обязательно, экономная по памяти бесконечность вычислений.

Например: генератор значений с накоплением результата, аналог reduce. Можно использовать для генерации графиков накопления кода в репозиториях в течении некоторого времени.

Если вместо дескрипторов использовать корутины то получаются кешированные атрибуты класса. next для чтения вместо __get__, send для новой калькуляции и перезаписи вместо __set__. Одинаково работает, но по коду получается короче.

@Andrey_SolomatinОтвет придет если упороться и написать ВЕСЬ код без return. Проект на 20.000-30.000 строк. В третьей части доклада тут рассказано, как это cделать. Много лет назад я начал использовать генераторы по приколу, а сейчас делаю это с пониманием зачем и почему.

Полностью согласен. В 99% времени генератор это просто удобный способ сделать итератор. В оставшемся 1% это сделать контекстный менеджер через contextlib

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации