The most distinctive feature of Pythomnic application modules is that
they are reloadable at runtime. You don't have to shut down the application
to add new modules or make changes to the existing ones. To employ
this feature, you use the pmnc construct
pmnc.bar.some_method(...)
^ reloading of module bar happens at this point
which handles the reloading invisibly. Although you could access the bar
module directly, as in
import bar bar.some_method(...)
this will lose the reloading guarantee and break everything and thus
should never be used in your Pythomnic application.
For a module to be correctly reloadable, it should either have no state
(be pure behaviour) or be prepared to being updated and reloaded. An example
of the former
@takes(list_of(int))
def pure_function(*args):
return sum(args)
# EOF
is obviously reloadable, but for the latter
sum = 0
@takes(int)
def accumulate(x):
global sum
sum += x
# EOF
to be reloadable, it should perform state migration, as the value of the
sum variable would be lost upon a reload. For this module to be successfully
reloaded it needs to migrate its state in response to pmnc_init call, which
is the first thing the platform does upon a reload. At this moment both
the new version and the old version exist and the new module can fetch
portions of the old module's state.
@takes(int)
def accumulate(x):
global sum
sum += x
def pmnc_init(old_module, new_module, new_module_filename):
if old_module:
new_module.sum = old_module.sum # state migration
else:
new_module.sum = 0 # initial value enters the module scope
# EOF
For simple state like that it works perfectly. However other modules may
have more complex state impossible to migrate. Other modules may simply
want to stay unreloadable, perhaps for security reasons, or because they
are just fine the way they are.
A module therefore can be marked as non-reloadable by inclusion of a specific
platform directive anywhere in the module:
__reloadable__ = False ... # EOF
Download
Documentation
Tutorial