1. Не используйте, пожалуйста, термин «планировщик green thread-ов» — такого объекта в gevent не существует.
2. Файловое i/o не имеет неблокирующей реализации в gevent — потому что linux kernel такое не умеет.
% никогда не уйдет из Python 3, если что.
Это не рекомендованный способ, но им можно пользоваться без опасений что разработчики его когда-то уберут (не в ближайшие двадцать лет — точно).
Если советуете выкинуть twisted, то почему не распространаете совет и на tornado?
asyncio принципиально похож на twisted/tornado ровно в том смысле, в каком программа на ассемблере похожа на программу на C: они ведь обе компилируются в машинный код!
С корутинами я хочу (и уже имею) несколько критически важных вещей:
1. Линейная структура кода. Все известные мне программисты мыслят линейно. Их можно научить думать в терминах обратных вызовов (я в свое время писал и для twisted и для tornado если что) — но это не совсем легко. В результате программа читается плохо и как минимум обработка ошибок очень страдает. Непойманные исключения улетают в никуда, это повсеместная проблема (кто-то где-то да забудет). Если исключение таки поймано, то у него ужасный traceback. В twisted предпринимали серьезные усилия чтобы этот traceback выглядел читаемо. С частичным успехом.
2. Удобная отладка. Если остановился на строчке с yield from, то 'next' переходит на следующую строку а не начинает отлаживать внутренности event loop.
3. Продуманный набор функций/классов для запуска, ожидания, отмены корутин, таймауты, блокировки, очереди и пр. В tornado.gen есть только очень куцый минимум того, что работает в asyncio
P.S.
twisted был великой библиотекой. Десять лет назад.
tornado, пожалуй, получше twisted. Но сравнение с asyncio с треском проигрывает. Единственное преимущество на сегодня — tornado.web, но за полгода и для asyncio появится достойная альтернатива (собственно говоря они уже есть но каждая в чем-то недоделана).
1. Пожалуйста.
2. Я начинал писать серию таких статей но застрял на полпути. Сделать что-то толковое требует немалого времени и драйва. Иначе ничего не выходит. Если статьи и появятся то точно не на хабре а у меня в блоге. Хабр ревнив и требует эксклюзивности, а это не нравится уже мне.
На callbacks писать не надо, это сложно и вообще может быть нужно только разработчикам библиотек. Если либы хорошие то пользователю кроме yield from ничего требоваться не должно.
P.S. Что такое AMA на Реддите в r/python не знаю, так что, наверное, замутить не хочу.
Вот вы сами и ответили на вопрос «зачем» — чтобы использовать библиотеки, сделанные для других систем. Причем если я создаю что-то для asyncio это можно будет использовать и в tornado. А наоборот не получится. Какую библиотеку делать перспективней?
P.S. Вообще-то торнадо научилась понимать asyncio event loop не так уж и давно — три месяца назад :)
Ссылка на pool остается в главном процессе.
Дочерние не закрываются, потому что главный может добавить в pool еще работу после того как дочерние отработали предудущие задания. С точки зрения дочернего процесса без дополнительных инструкций не понять, предполагает ли главный процесс как-то еще использовать pool или нет.
Для пользовательских типов данных — да, чаще всего будет неатомарно.
2. Файловое i/o не имеет неблокирующей реализации в gevent — потому что linux kernel такое не умеет.
ресурсоемкие -> блокирующие ввод-вывод (IO bound)
Которая имеет свои подводные камни и особенности, и никогда не войдет в стандартную библиотеку.
Это если коротко.
Это не рекомендованный способ, но им можно пользоваться без опасений что разработчики его когда-то уберут (не в ближайшие двадцать лет — точно).
Так было надо.
Если что непонятно — спрашивайте
asyncio принципиально похож на twisted/tornado ровно в том смысле, в каком программа на ассемблере похожа на программу на C: они ведь обе компилируются в машинный код!
С корутинами я хочу (и уже имею) несколько критически важных вещей:
1. Линейная структура кода. Все известные мне программисты мыслят линейно. Их можно научить думать в терминах обратных вызовов (я в свое время писал и для twisted и для tornado если что) — но это не совсем легко. В результате программа читается плохо и как минимум обработка ошибок очень страдает. Непойманные исключения улетают в никуда, это повсеместная проблема (кто-то где-то да забудет). Если исключение таки поймано, то у него ужасный traceback. В twisted предпринимали серьезные усилия чтобы этот traceback выглядел читаемо. С частичным успехом.
2. Удобная отладка. Если остановился на строчке с yield from, то 'next' переходит на следующую строку а не начинает отлаживать внутренности event loop.
3. Продуманный набор функций/классов для запуска, ожидания, отмены корутин, таймауты, блокировки, очереди и пр. В tornado.gen есть только очень куцый минимум того, что работает в asyncio
P.S.
twisted был великой библиотекой. Десять лет назад.
tornado, пожалуй, получше twisted. Но сравнение с asyncio с треском проигрывает. Единственное преимущество на сегодня — tornado.web, но за полгода и для asyncio появится достойная альтернатива (собственно говоря они уже есть но каждая в чем-то недоделана).
2. Я начинал писать серию таких статей но застрял на полпути. Сделать что-то толковое требует немалого времени и драйва. Иначе ничего не выходит. Если статьи и появятся то точно не на хабре а у меня в блоге. Хабр ревнив и требует эксклюзивности, а это не нравится уже мне.
На callbacks писать не надо, это сложно и вообще может быть нужно только разработчикам библиотек. Если либы хорошие то пользователю кроме yield from ничего требоваться не должно.
P.S. Что такое AMA на Реддите в r/python не знаю, так что, наверное, замутить не хочу.
P.S. Вообще-то торнадо научилась понимать asyncio event loop не так уж и давно — три месяца назад :)
Возвращаясь к теме. Написал статью «почему нет http в asyncio»: asvetlov.blogspot.com/2014/04/wsgi.html
Дочерние не закрываются, потому что главный может добавить в pool еще работу после того как дочерние отработали предудущие задания. С точки зрения дочернего процесса без дополнительных инструкций не понять, предполагает ли главный процесс как-то еще использовать pool или нет.