Hot reloading is next to impossible to do safely in the general case in Python, and this library is really basic and doesn’t really do anything special.
The only case where it does work is if you maintain a single reference to the module you wish to reload, _and_ the target module doesn’t load any C extensions, _and_ it doesn’t create state outside its module (very easy to do accidentally).
That’s why every autoreloader implementation restarts the whole process when any change is made, because how would you even detect that it was safe to hot reload something in the general case let alone actually hot reload it safely?
If you need to add an autoreloader to your project use Hupper[1]. If you’re weird like me and you’re interested in autoreloaders, check out the Django[2] and Flask[3] implementations or my talk[4] for more details.
I got it working well in a large project but I basically designed auto reloading into deep parts of the framework. It's not something you can safely bolt on, and I'm honestly not sure I recommend the sanity impact of trying to build it properly (e.g. ran into a bunch of memory leaking even once I had it working safely). But there are some kinds of programs you can't really restart on every change.
The biggest caveat of these kinds of single file reloaders is they completely fall apart when you import between your modules. For example, if `a` does `from b import obj` and `b` does `from c import obj`, and you modify `c.py`, `a` and `b` will both have a stale reference to obj (which might be a primitive or even interned type like a string or an int, so it's not like you can mutate it as a solution).
I updated my comment to say “impossible in the general case” which is more accurate, but I’d be interested in knowing more about that project - how big was it, and how did handle some of the tricky bits?
Like, module A creates a class/function that is consumed by module B and C. If you change module A, how did you know to also reload B and C (recursively)?
This is for a scriptable desktop accessibility program. It is fairly big, is very actively used by end users, and many users have >80 modules and edit them _constantly_ during daily use. So the reloading system isn't just commonly used, it's a critical path of using the app. (I also have not gotten any complaints related to the module reloading in ~months, when I last fixed a bug in the long dependency chain tracking, and reloading hasn't caused any major problems in general).
I slightly break the mold of conventional Python imports - script folders don't have a single entry point, the entire user script directory tree is recursively imported (in alphabetical order) and autoreloaded on change.
Anytime I call into a module it is marked as the active module in its thread (a sort of call stack but at the module level and only for certain kinds of events).
"Call into" generally means the module is being imported, or I'm calling a callback that was registered by the module.
Anytime code creates a global object (such as opening a window, registering new voice commands, or registering a callback for some kind of event), cleanup for the object is registered on the active module. Additionally, all imports are tracked, so I have a graph of which modules import which other modules.
The import tracking allows me to reload dependent module chains (even long chains, trees, or import loops) at the correct time. The object tracking allows me to gracefully replace a module without it requiring any explicit cleanup.
This graph extends to more than just Python files. There are special functions for opening or reading files that mark those files as a module's dependencies as well, so you can modify something like a CSV and the script that uses it will get reloaded (and any module chains that depend on that script).
This all working well is tightly coupled to how the framework behaves. Scripts won't generally spawn threads or spin in long loops, they'll mostly register for event callbacks. For example, instead of a script spawning a thread or sleeping if it wants to run code later, there's a cron system that works something like javascript setTimeout/setInterval. Instead of storing something in a global, you can put it in the persistent storage layer if you want it to survive reloads (and restarts).
You can definitely do a few things that aren't reloadable, like spawning your own thread, but most things you want to do end up being reloadable, or have an equivalent or alternative API that is reloadable.
There are a few other nice touches and APIs that help glue all of this together. Generally it means you can write your scripts as short, flat, mostly declarative Python (with perhaps a few event handlers and setup code that don't need to go in a __main__ guard) and not worry about common cases for reloading. (There are also subsystems specifically watching out for edge cases, such as a user script running an infinite loop)
Honestly the most annoying part of all of this (that I do generally handle now) was reliably monitoring file changes when users put file or directory symlinks at arbitrary places in the tree (which it turns out a lot of users like to do).
In python 2, you could use the gc module to get a list of every reference to a certain object. Using this, you could replace all references to that object with references to some other object. For references occurring in immutable things like tuples, you would need to replace the immutable thing recursively.
While the docs say that this shouldn't be used for any purpose other than debugging, it never caused any trouble IME. Far more trouble was caused by classes from python's stdlib just blatantly not following the pickle protocol, not calling __init__, calling __init__ more than once, etc. I assume this is why people advised me to use composition rather than inheritance when making classes that were a list with extra behavior, a dict with extra behavior, and so on.
Edit: Well, the above primitive is not enough on its own, but if one gets the old module and the new module and explores outwardly from those to find the subset of the object graph that differs, then one can replace all references to the old things with references to the new things. This is still not enough in general, because you'll have e.g. a bunch of objects that never had a certain member set during __init__ because __init__ was different when they were created. You'll probably meet an additional can of worms if you want to use __slots__ and add or remove class members.
Because of the nature of Python, using importlib.reload() is going to lead to terrible bugs at some point. Use importlib.reload() only in the shell, for convenience.
If you want autoreload for dev (e.g: like django dev server), better restart the entire process.
There is a 7 years old project that can help you with that called watchdog:
https://pythonhosted.org/watchdog/
It's a library that uses the fastest way available (e.g: inotify,kqueue...) to react to file changes (you can filter by types such as create, delete, write, etc) and triggers whatever code you want, passing you the metadata.
If you just want something very simple, you don't have to code, you can install watchdog with its optional watchmedo dependancy:
pip install watchdog[watchmedo]
It will give you the watchmedo command, that lets you do something like this:
Yes but unfortunatly, you have to compile it for many systems yourself. And if you want to use it from Python (not from the command line), you need binding.
On the other hand, it's probably more performant than watchdog if you have a lot of files and need to fallback on manual watching.
Plus, if you are not a Python person, you may not want to use pip.
Does this "just work"? How does it handle classes?
I've been writing my python code in a style that can be hotswapped. Roughly, I use global functions and pass around structs, like C. The function calls are made with `api.foo(data)` instead of `data.foo()`. Then I can just replace `api.foo`'s definition with whatever I want after attaching with a debugger. Example: https://github.com/shawwn/gpt-2/blob/e4868225382e8a475ef3c3d...
I assume there's a much better way to do this, but the class system seems to make it hard to swap things out. Doesn't "isinstance" break if you redefine the class?
EDIT: Oh, this isn't actual hot-reloading for python. Darn. I'm really hoping someone will tackle that... Cool project though!
By the way, you may want to use `import traceback; traceback.print_exc()` to log exceptions. I'm not sure how that plays with python's `logger` class though.
> By the way, you may want to use `import traceback; traceback.print_exc()` to log exceptions. I'm not sure how that plays with python's `logger` class though.
PSL logging has builtin integration with exception tracebacks. See Logger.exception [1] or the exc_info keyword param to Logger.debug/info/warning/error/critical/log [2].
I couldn’t live without ipython autoreload. You need to know where the limitations are that require you to create your instances again. Things like sqlalchemy model changes run into issues because of the meta class magic (I think, not looked too deeply).
I feel like this library is a bit misrenamed. It seems to be more like “autorun”.
It used to do hot reloading back in the days but unfortunately that doesn’t really work in Python because of all the import side effects. It’s better to restart everything.
Werkzeug keeps the socket open so you don’t observe the reload from the outside.
Actual reloading is just hairy and you can end up with semi-broken instances among other things. Restarting the interpreter is just cleaner, and it's totally acceptable for a dev server. (Okay looks like Armin himself replied too, obviously take his words above mine.) I pointed to IPython's autoreload in another reply which is more powerful than importlib.reload.
As other have pointed out, the best way is to restart the process. If you are looking for hot reloading you should look at programming languages that run in BEAM like Erlang and Elixir[1].
There are some gotchas with hot swapping, but it's designed and used in production for many years [2].
If somebody knows other languages/systems that do let me know.
It's relatively easy to do in Lua, depending on how you organize modules. Imported libraries are just plain tables (dictionaries) instead of a language-level feature, so hot swapping means just clearing the table and replacing its contents with the ones loaded from disk. I think it is easier to do because there is less magic in the modules system; it's implemented on top of the language itself.
I've used this technique in multiple games written in Lua, as well as a GUI app written with wxLua, and I can't imagine programming a long-running program in Lua again without it.
There are many caveats like stale module local state but they can be circumvented by designing the program from the start to put such state into a separate module which gets preserved. You do also have to modify your program's code to accommodate hot swapping in some cases but I would say the effort is repaid many times over in time saved not having to restart the program and go all the way back to part you're testing again every time you make a change.
I really wish it were easier to do in popular languages like Python but because of the way it interacts with imports I feel like your only chance to get it right is in the early stages of language design. One time I was wanting to program games in Typescript to take advantage of gradual typing but couldn't figure out an equivalent way to do hot reloading like in Lua, so I went with Lua instead. I feel like if more people knew how much benefit it brings from using a language that supports it we might see more mainstream support in new dynamic languages.
> If somebody knows other languages/systems that do let me know.
Clojure can do this via namespace live reload. ClojureScript is already doing this inside figwheel [1] environment. CommonLisp had this since dawn of time. Kawa [2] can do it, but because it aggressively optimize the code, you need to be careful. Racket can do it as well [3].
Java with DCEVM or OSGi. This was originally a big OSGi selling point if I recall correctly though I’ve never seen it successfully implemented - though maybe in the Eclipse IDE?
Anyway it’s a very well studied and covered topic in the Java ecosystem as I understand it...
;; define a map
(def myvar (atom {:foo 1}))
;; add watcher for 'myvar'; it will call anonymous
;; function and set old-state with previous value and new-state
;; with new value, when 'myvar' was changed
(add-watch myvar :dummy
(fn [_ _ old-state new-state]
(println "changed! - old: " old-state " new: " new-state)))
;; Run separate thread and and update :foo value to 2, after 6 seconds.
;; No scheduling is necessary, this is so it can be evaluated in REPL easily.
(future
(Thread/sleep 6000)
(swap! myvar assoc :foo 2))
;; Infinite loop. Sleep for 0.5 seconds just for printing purposes.
(loop []
(println @myvar)
(Thread/sleep 500)
(recur))
I used different thread just for printing/add-watch purposes.
But, using myvar or your-like example (hot loading function) in the same thread works without any problems as well - put function in a loop, change function body and reload namespace where myvar/function exists - loop will pick that up instantly.
In your example, you modified the assoc while another thread was accessing it. That is a standard feature of languages with threading support and is not impressive.
Let me give you a clearer example than my first one:
def fn():
d = {'name' : 'hello'}
while True:
print(d['name'])
threading.Thread(target=fn).run()
This causes a thread to be started which prints "hello" indefinitely. Clojure cannot, while the thread is running, change the execution to, say:
def fn():
d = {'name' : 'there'}
while True:
print(d['name'])
time.sleep(0.5)
Clojure cannot change the value of the local variable d because it has no reference to it. Clojure cannot add the line time.sleep(0.5) to the loop because it has no facility for "upgrading" running threads.
Reading up on the Erlang system, it doesn't upgrade function-local state this way either. It relies on a convention where this state is stored externally to the function by the gen_server framework and passed in, right?
Yes and no. Like everything in Erlang, hot-swapping relies on code being structured as servers that responds to messages. In this case, the VM sends a message to the process telling it about the code upgrade. The process has to handle this message "manually" and do what it needs with it. For example, changing its internal state or updating database schema if it uses external storage.
But you don't have to use the gen_server framework to accomplish this. It's perfectly fine (but not recommended as there are lots of details you want to get right) to write your own code for handling hot-swapping. See http://erlang.org/documentation/doc-4.9.1/doc/design_princip... for some details on server principles.
Immutability in combination with Erlang's process centric view is what makes it possible.
there are also lesser known languages such as pike. although pike doesn't do hotswapping of actual objects but only allows the hotswapping of the compiled classes used to instantiate new objects. this works well enough on webservers where new objects are created for every request, and only live as long as the request is processed.
there is a platform called open-steam that emulates hotswapping by using proxy objects. when i reference an object, i actually get a proxy, that then references the real object. when i update the code, then the proxy gets updated to the new real object, and for me it looks like the object i am referencing has been hotswapped.
Looks like it starts a thread that repeatedly hashes the content of the target script to poll for changes. Watchdog uses OS features like inotify and FSEvents and only uses polling and comparing hashes as a fallback.
Looks like it uses hashlib to check the file for changes, which is a nice way to make it cross-platform compatible.
For those who run on linux, you can use the inotify tools to set up a watch on a file (or directory or recursive directories). inotify uses kernel events and won't require re-reading and re-hashing the file.
Don’t hot swap. Just don’t do it. 99.99% of us should never need to do it. Learn sound network topology and load balancer practices instead. Embedded? Your hardware documentation will tell you how to offload this problem to it. There’s no earthly reason for most of us to be learning this.
having an infinite loop reading the file and calculating its sha checksum every 1s is not ideal. I'd suggest using the OS premitives to get notifications when the file is touched (inotify on linux and ReadDirectoryChangesW on windows), or simply use the watchdog lib
When I add autoreload functionality to my programs I just spawn a thread that checks for last modified date and then re-executes the program with os.execlp(sys.argv[0], *sys.argv)
I found my solution superior in several ways:
- I can force an autoreload just by saving a file (no file changes needed to force an md5 diff)
- exec() doesn't suffer from the side effects of not restarting the python interpreter, clean start every time :)
- it is also quite portable and doesn't require extra dependencies like inotify/fswatch/etc.
</ul>
Have a look at https://github.com/julvo/reloading, it's a little library I wrote that can give you edit-code-and-continue-debugging in Python loops. A more general solution for this sort of development in Python would be neat though.
Not keen on hashing the file every second but I understand why... I'd rather it used filesystem modification events and responded accordingly. But that might more more complex than what you intend.
But for simple scripts being live-coded that need to be quickly "up" and hot-swapped on rapid modification this looks fine. I could always increase the delay to a minute or hour or more if the changes were only occasionally changed.
The only case where it does work is if you maintain a single reference to the module you wish to reload, _and_ the target module doesn’t load any C extensions, _and_ it doesn’t create state outside its module (very easy to do accidentally).
That’s why every autoreloader implementation restarts the whole process when any change is made, because how would you even detect that it was safe to hot reload something in the general case let alone actually hot reload it safely?
If you need to add an autoreloader to your project use Hupper[1]. If you’re weird like me and you’re interested in autoreloaders, check out the Django[2] and Flask[3] implementations or my talk[4] for more details.
1. https://pypi.org/project/hupper/
2. https://github.com/django/django/blob/master/django/utils/au...
3. https://github.com/pallets/werkzeug/blob/master/src/werkzeug...
4. https://youtu.be/IghyoR6ld60