Code reloading support library for Python
Project description
This library implements something which is often called live coding or code reloading. It allows an application to have Python code which might be part of it updated as the files the code is in are changed - while the application is running.
No need to restart the application in order to incorporate changes made to Python scripts.
No need to execute Python scripts manually each time you want to use the code within them.
This library will not allow you to have your existing Python modules reload. Please visit the project home page if you wish to understand why. This is a custom solution, not a band-aid for your existing practices.
Changes from version 2.01:
MODE_OVERWRITE is recognised as not working properly and now MODE_UPDATE is the default option.
Now uses the ‘logging’ module from the standard library for output, whether for debugging or just related to normal usage.
Unit testing for managed scripts was only done when the script was first loaded, not when it was subsequently modified and reloaded. Now it happens in both cases.
When unit tests are located for a managed script, how many were found for that script are logged as normal usage output.
Exceptions that occur during the loading or reloading process are now displayed through ‘logging.exception’, rather than through custom means based around the ‘traceback’ module.
If the internal monitoring of file changes is used, depending on which method it chooses to use to monitor, it may do it in a Python thread. If this thread is prevented from exiting with the garbage collection of the code reloader, then the main Python thread and therefore whatever application is running will not exit until the other thread does as well. The other thread can be made to exit, but using the new ‘EndMonitoring’ function.
The ‘filechanges’ module was passing notification of all file changes within the directories it monitored. Now it only passes on changes to files with a name ending in ‘.py’.
For every changed script that MODE_UPDATE loaded and put into effect, if there were classes in a script with functions defined on them, those classes would be leaked. Under this mode, those scripts and the objects within them, like classes are not necessarily used.
Added a way to get callbacks when classes are updated. This is done by passing a function or method to ‘SetClassUpdateCallback’ on the code reloader.
Under MODE_UPDATE, when classes were processed and their functions were moved over from the updated script that had been loaded to the original script, they were not rebound. This meant they were referencing the globals dictionary of the temporary script, rather than that of the original script where they were going. Now the rebound functions are used, rather than just being created and ignored.
When a script is garbage collected, its globals dictionary is explicitly cleared. This should highlight problems with faulty code reloading, and it also works around a class leakage problem too (issue 12).
