Можно ли программно построить кадр стека Python и начать выполнение в произвольной точке кода?

Привязки expat python, включенные в обычный дистрибутив Python, программно создают кадры стека. Однако будьте осторожны, он использует недокументированные и частные API.

http://svn.python.org/view/python/trunk/Modules/pyexpat.c?rev=64048&view=auto

Обычно вам нужны продолжения, которые, как я вижу, уже являются тегом этого вопроса.

Если у вас есть возможность работать со всем кодом в системе, вы можете попробовать сделать это таким образом, а не иметь дело с внутренностями стека интерпретатора. Я не уверен, насколько легко это будет сохраняться.

http://www.ps.uni-sb.de/~duchier/python/continuations.html

На практике я бы структурировал ваш механизм рабочего процесса так, чтобы ваш скрипт отправлял объекты действия менеджеру. Менеджер может выбрать набор действий в любой момент, разрешить их загрузку и начать выполнение снова (возобновив отправку действий).

Другими словами: создайте свой собственный стек на уровне приложения.

Python без стеков, вероятно, лучший… если вы не возражаете полностью перейти на другой дистрибутив Python. stackless может сериализовать все в python, а также свои тасклеты. Если вы хотите остаться в стандартном дистрибутиве Python, я бы использовал dill, который может сериализовать почти что угодно в Python.

>>> import dill
>>> 
>>> def foo(a):
...   def bar(x):
...     return a*x
...   return bar
... 
>>> class baz(object):
...   def __call__(self, a,x):
...     return foo(a)(x)
... 
>>> b = baz()
>>> b(3,2)
6
>>> c = baz.__call__
>>> c(b,3,2)
6
>>> g = dill.loads(dill.dumps(globals()))
>>> g
{'dill': <module 'dill' from '/Library/Frameworks/Python.framework/Versions/7.2/lib/python2.7/site-packages/dill-0.2a.dev-py2.7.egg/dill/__init__.pyc'>, 'c': <unbound method baz.__call__>, 'b': <__main__.baz object at 0x4d61970>, 'g': {...}, '__builtins__': <module '__builtin__' (built-in)>, 'baz': <class '__main__.baz'>, '_version': '2', '__package__': None, '__name__': '__main__', 'foo': <function foo at 0x4d39d30>, '__doc__': None}

Dill регистрирует свои типы в реестре pickle, поэтому, если у вас есть какой-то код черного ящика, который использует pickle, и вы не можете его редактировать, то простой импорт dill может волшебным образом заставить его работать без обезьяньих исправлений стороннего кода.

Вот dill травит весь сеанс интерпретатора...

>>> # continuing from above
>>> dill.dump_session('foobar.pkl')
>>>
>>> ^D
dude@sakurai>$ python
Python 2.7.5 (default, Sep 30 2013, 20:15:49) 
[GCC 4.2.1 (Apple Inc. build 5566)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import dill
>>> dill.load_session('foobar.pkl')
>>> c(b,3,2)
6

dill также содержит несколько хороших инструментов, которые помогут вам понять, что вызывает ваше травление, чтобы потерпеть неудачу, когда ваш код терпит неудачу.

Вы также спросили, где он используется для сохранения состояния интерпретатора?

IPython может использовать dill для сохранения сеанса интерпретатора в файл. https://nbtest.herokuapp.com/github/ipython/ipython/blob/master/examples/parallel/Using%20Dill.ipynb

klepto использует dill для поддержки кэширования в памяти, на диске или в базе данных, что позволяет избежать повторных вычислений. https://github.com/uqfoundation/klepto/blob/master/tests/test_cache_info.py

mystic использует dill для сохранения контрольных точек для больших заданий по оптимизации, сохраняя состояние оптимизатора по мере его выполнения. https://github.com/uqfoundation/mystic/blob/master/tests/test_solver_state.py

Есть пара других пакетов, которые используют dill для сохранения состояния объектов или сеансов.

Вы можете захватить существующий кадр стека, выдав исключение и отойдя на один кадр назад в трассировке. Проблема в том, что нет способа возобновить выполнение в середине (frame.f_lasti) блока кода.

«Возобновляемые исключения» — действительно интересная языковая идея, хотя сложно придумать разумный способ, которым они могли бы взаимодействовать с существующими в Python блоками «try/finally» и «with».

На данный момент обычный способ сделать это — просто использовать потоки для запуска вашего рабочего процесса в отдельном контексте от его контроллера. (Или сопрограммы/гринлеты, если вы не возражаете против их компиляции).

Со стандартным CPython это осложняется смесью данных C и Python в стеке. Перестроение стека вызовов потребует одновременного восстановления стека C. Это действительно ставит его в слишком тяжелую корзину, поскольку потенциально может тесно связать реализацию с конкретными версиями CPython.

Stackless Python позволяет мариновать тасклеты, что дает большую часть необходимых возможностей из коробки.

У меня такая же проблема, которую нужно решить. Интересно, что решил сделать оригинальный постер.

stackless утверждает, что может собирать тасклеты, если нет связанного «загроможденного» стека C (перегруженный - мой выбор фразы).

Я, вероятно, буду использовать eventlet и придумаю какой-нибудь способ травления «состояния», хотя я действительно не хочу писать явный конечный автомат.

Как насчет использования joblib?

Я не совсем уверен, что это то, что вы хотите, но, похоже, это соответствует идее рабочего процесса, в котором этапы могут быть сохранены. Вариант использования Joblib, по-видимому, заключается в том, чтобы избежать пересчета, я не уверен, что вы пытаетесь сделать это здесь или что-то более сложное?