Ответ 1
Существует много информации об этом. Для "официального слова" по этому вопросу прочитайте (закрытый) вопрос об ошибке Python.
Основная аргументация одного из людей, принявших решение, подробно описана в в этом блоге:
Поскольку генератор - это сугубо функция, нам нужно сохранить его байт-код, который не гарантирует обратную совместимость между версиями Pythons и его фреймом, который содержит состояние генератора, такое как локальные переменные, замыкания и указатель команд. И это последнее довольно громоздко, потому что в основном это требует, чтобы весь интерпретатор был сорван. Таким образом, любая поддержка генераторов травления потребует большого количества изменений в ядре CPythons.
Теперь, если объект, не поддерживаемый pickle (например, дескриптор файла, сокет, соединение с базой данных и т.д.), встречается в локальных переменных генератора, тогда этот генератор не может быть маринован автоматически, независимо от поддержки рассола для генераторы, которые мы можем реализовать. Таким образом, в этом случае вам все равно необходимо предоставить настраиваемые методы
__getstate__и__setstate__. Эта проблема делает любую поддержку травления для генераторов весьма ограниченной.
И упоминаются две предложенные обходные пути:
В любом случае, если вам нужна такая функция, загляните в Stackless Python, который сделает все выше. А так как интерпретатор Stacklesss является граблированным, вы также получаете бесплатную миграцию процесса. Это означает, что вы можете прервать тасклет (имя для зеленых потоков Stacklesss), рассолить его, отправить рассол на другую машину, разложить ее, возобновить тасклет, а voilà вы просто перенесли процесс. Это потрясающая функция!
Но по моему скромному мнению, наилучшим решением этой проблемы переписать генераторы как простые итераторы (т.е. один с методом
__next__). Итераторы легки и эффективны в пространстве для рассола, потому что их состояние является явным. Однако вам все равно придется обрабатывать объекты, представляющие какое-либо внешнее состояние; вы не можете обойти это.