:)
Вопрос: Почему у python нет функций сохранения на диск полного состояния интерпретатора и восстановления этого состояния?

А именно в чем концептуальные плюсы и минусы такого свойства?

Можно придумать достаточно много способов применения этой фичи.

Плюсы:
1. У пользователя навернулась программа. Он вам шлет полное состояние. Разбирайся - все под рукой. Это более полный аналог core dump. Прям как анатомичке - вот вам globals вот вам стек программ, а вот рядом с селезенкой - gc прилепился… Опять-же студентам на лекции по питону рассказывать про его устройство будет проще. Сейчас можно для этого использовать отладчик, Но 50 работающих питонов это уже перебор.

2 Как в играх. Отлаживал отлаживал, интерпретировал интерпретировал. Перед важным моментом бабах - save game. И можно на обед прерваться и не бояться краха всего после очередной инструкции.

3 Как показывает практика часто надо сравнивать состояния системы до и после внесения изменений - один из вариантов - сравнить дампы (конечно нужно чтобы у них можно было сравнивать части).

Конечно есть и сложности. Не сохраняется окружение программы - открытые сокеты файлы, состояния подгружаемых бинарных библиотек. Формат файла скорее должен быть иерархическим а не потоковым чтобы было проще разбираться. Что такое состояние программы на текущий момент в многопоточном приложении это тоже отдельный философский вопрос.

Это вопрос и к молодым и к более опытным коллегам. Может я просто не знаю и эти функции есть? Если нет, может нам для трешки их сделать? Как бы вы могли использовать такие функции?

Если реализовать - то питончик будет круче всех ЯП. Я по крайней мере не знаю других языков имеющих подобную функциональность.

звучит интересно с точки зрения технической фичи. На счет всего остального думаю думы.

а если с помощью pickle засуспендить globals() и locals()?

1. Чтобы получить расширенную информацию Питон нужно собирать с ключом –with-pydebug, но это скажется на производительности, поэтому для продакшн не подходит.
2. Остальное можно получить с помощью sys, inspect и traceback.
3. Существует ли готовый модуль для облегчения работы с п.2 я не знаю. Если да, то как его заставить переключаться между режимами production, debug на лету?
Часть информации можно снять в обработке исключений или contextlib, но это увеличит кол-во кода. Стоит ли шкурка вычинки?

wbt
а если с помощью pickle засуспендить

Тогда уж locals() globals() и состояние стека. Я так и делаю в сложных случаях. Вопрос в том что может быть полезно еще уметь восстанавливать состояние VM. Это дело уже ядра системы. Кроме того обычные пиклы не очень удобны для offline анализа. Дело в том что при их загрузке надо чтобы были известны все классы, а классы как вы понимаете тоже будут в этих пиклах. :) т.е. не получается универсальной утилиты для анализа пиклов. Может их парами сохранять? Не универсальный инструмент рассчитанный только на встроенные типы мы уже для себя сделали (поддерживаются list map,numpy,ctypes объекты). Правда на wxPython. Наверное надо будет переделать в ближайшем будущем.

Lexander
Питон нужно собирать с ключом …

Безусловно надо чтобы работало в продакшене. Иначе оно вообще смысл теряет. И конечно большая часть информации доступна и так. Не зря питон славится хорошими возможностями по интроспекции.

Для почитать о состоянии дел по теме core dump и его анализа:
http://www.zemanta.com/blog/python-gdb-large-core-dump/

Ну и пару приемов, кроме общесистемного core dump, который обычно автоматически пишет система при seg fault процесса или с помощью системных утилит для получения core dump процесса:
1. https://github.com/gooli/pydump
2. программный вызов os.abort() внутри программы, по идее тоже должен вызвать перехват ситуации системой и последующий автоматический core dump

не core dump, но сохранение состояния есть у twisted, в twistd stop команде