реально ли обновлять питон-код в уже запущенном скрипте?

Вообще - реально. Как ты это сделаешь в уже работающем скрипте без его остановки для меня загадка, так что подпишусь.

Вообще - реально. Как ты это сделаешь в уже работающем скрипте без его остановки для меня загадка, так что подпишусь.

Если он реально готов это делать каждый раз, то он может считывать код из файла и делать eval.

https://docs.python.org/2/library/functions.html#reload

Не оно?

По идее можно через pickle сериализовать любой класс.

Не, мне интересно как он это сейчас провернет на уже работающем скрипте.

Помнится пару месяцев назад уже была такая тема. А может не пару месяцев. Но вроде в этом году было.

Можно. Только после сброса на диск надо модуль с этим классом выносить из sys.modules что бы он переимпортировался.

Другой вариант - если все данные висят в виде встроенных типов данных питона (ну или типы данных обновлять не планируется), то можно каждый раз делать reload модуля с функциями работы над этими данными.

А так что бы ВЕСЬ код демона обновить... наверное если только скинуть на диск его состояние и перезапучтить процесс.

реально!

удаляешь нужный модуль из ``sys.modules[...]`` и затем импортируешь его поновой.

(уже созданные экземпляры классов — так и останутся созданными. а новые экзесплары классов — будут иметь обновлённое поведение!)

только смысла в этом нет — так как уж лучше сразу перезапускать демона (в случае если обнаруживается изменение в его кодовых файлах.. или вообще вручную перезапускать демона — это ещё лучше!).

Ты хочешь прямо таки лиспа какого-нибудь или smalltalk'а я полагаю.

gdb call? А что, любителей вызвать таким образом setenv(…) полно, а тут — пффф! — всего лишь несколько (…десятков) лишних функций выучить!

необходимо внести небольшое изменение в его код, без перезапуска демона

Use Lisp, Luke!

import

Flask как-то это умеет делать.

Нормального релода как в каком-нибудь ерланге в питоне нет.

скажем, есть юзернейм, которому надо внести изменения в скрипт на питоне

но учить питон или гуглить юзернейм не хочет, а хочет, чтобы ему подсказали ответ на ЛОР'е

реально ли, например, чтобы лоровцы никогда не получали таких тем в Development?

насколько вообще это осуществимо?

легко осуществимо

ДА!

Это реально.

Интерпретатор же не компилятор, строчка за строчкой, так что в цикле или по таймауту вызываешь

import your_module_name

При этом можно через

sys.path.append( WORK_DIR )

добавить рабочую директорию, в которой лежит модуль.

отлично, получилось

https://duckduckgo.com/?q=erlang for python programmers

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

В питоне даже рядом аналогов нет и не будет.

Да ладно, даже на Java (Play) и в Go (Revel) это обыденность.

Вот тебе простой пример, делаю джаббер-бота, на ошибке при обработке сообщения тред падал в дебаггер (чего в джавах и го точно нет), в котором нужно было интерактивно выбрать соответствующий рестарт. Я переопределил символ, из пакета xmpp, который первым хендлит сообщения так, чтобы он складывал ошибку в список ошибок и продолжал работу.

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

И кстати пример расширения класса в java/go я бы хотел увидеть. Как реагируют объекты класса на добавление полей в класс? На удаление? На создание новых методов? На удаление методов?

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

А вобще релоад кода на питоне очень хорошо продемонстрирован тут https://github.com/django/django/blob/master/django/utils/autoreload.py#L282

И что значит даже, питон не может в перезагрузку символов когда они импортированы в других пакетах

Питон — хотя бы динамический. В отличие от Golang и Java.

А коммон лисп вобще компилируемый)

А коммон лисп вобще компилируемый)

Компилируемые сегодня почти все. Из популярных интерпретируемые только bash и tcl :)

Еще руби не может в компиляцию, а питон, джава и прочие не компилятся в натив.

У нас на бою сервак 24/7 крутится, нельзя просто взять и остановить... Написали свой интерпретатор команд и терминал. Терминал отправляет команду (сериализованную) на сервак, а сервак передает интерпретатору, тот ее eval-ом выполняет... Т.о. мы постоянно через reload перезагружаем пофикшенные модули... плюс, спокойно смотрим внутренности постоянно живущих объектов, и можем менять им значения... Но тут еще архитектура важна... у нас система реального времени, если ошибка возникла, то этой в сессии (набор объектов, выполняющих бизнес-логику и живущих на своем пуле потоков) ничего зарелоадить не получится, но можно ручками поменять значения и продолжить выполнение функции, а вот уже следующая такая сессия будет с измененным кодом...

Еще руби не может в компиляцию, а питон, джава и прочие не компилятся в натив.

Компиляция — это объективный самостоятельный критерий. Это предварительная трансляция перед исполнением.

«Компиляция в натив» — это частный случай, к тому же релативный. Скажем, компиляция в код x86 не будет нативной для ARM, а компиляция в байткод JVM не будучи нативной для x86, будет нативной для Java-процессоров. Реализуй PHP-процессор для байткода PHP, тогда и PHP будет тоже компилировать в нативный код. Если какая-то классификация начинает менять смысл при не связанных с ней и её объектами внешних изменениях, то она довольно мало полезна.

Такое делается даже без особых извращений, т.к. питон умеет импортировать модули в рантайме. Нет никаких проблем до тех пор пока модулю не нужно перезагружать самого себя, но это же не обязательно делать, верно?

Это все демагогия, на моем ноуте лисп компилится в натив, на сервере компилится в натив, и это очевидное преимущество. Когда появятся процессоры выполняющие байткод пхп и джавы - тогда обсудим твои идеи.

Когда появятся процессоры выполняющие байткод пхп и джавы - тогда обсудим твои идеи.

Про Java ты отстал лет на 15. man java-процессоры.

Ещё раньше можешь посмотреть на пример Форта. Тоже виртуальный код на x86, но реальный — на Форт-процессорах.

Это не демагогия, это твоя узкая x86-ориентация. В то время, как мир заметно шире.

...

И, да, Java давно компилируется и в x86-машинный код. man JIT.

java-процессоры

Ну и где они? Про кредитные карты слышал.

Это не демагогия, это твоя узкая x86-ориентация

Разве я говорил только про x86?

Разве я говорил только про x86?

Ну тогда тебя не должно удивлять, что x86 «нативный» код перестаёт таким быть для ARM или MIPS.

sbcl на линуксе умеет в натив для этих архитектур: X86 AMD64 PPC SPARC Alpha MIPSbe MIPSle ARMel ARMhf, была бы нужда в компиляции для php-процессора - был бы и он.

sbcl на линуксе умеет в натив для этих архитектур

А Perl умеет натив для Perl-виртмашины.

А процессор на моем ноуте не выполняет инструкции перл-машины.

А процессор на моем ноуте не выполняет инструкции перл-машины.

Это проблемы твоего процессора. А частные проблемы процессоров не должны влиять на общие дефиниции.

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

Опять же, примеры с Forth и Java-процессорами ты проигнорировал.

java-процессоры

Ну и где они?

Нужно быть чуть-чуть эрудированнее. Уже скоро 20 лет их появлению:

http://www.osp.ru/cw/1997/42/25003/

Форт-процессоры, соответственно, ещё старше. Они к 1980-м восходят.

Уже скоро 20 лет их появлению:

А вопрос не про появление.

А частные проблемы процессоров не должны влиять на общие дефиниции.

С таким успехом все должны писать на типизированном лямбда исчислении и не думать о железе. А на деле мы с тобой общаемся по реальному интернету, сервера которого работают на реальном железе, которое включает в себя конкретные процессоры. Ничего бы этого небыло, если бы частные проблемы не влияли бы на общие дифиниции.

С таким успехом все должны писать на типизированном лямбда исчислении и не думать о железе

В общем, так и есть. При написании подавляющего большинства программ сегодня о железе думать не приходится. И слава Богу.

Ничего бы этого небыло, если бы частные проблемы не влияли бы на общие дифиниции

А в Киеве — дядько.