HomePage: http://cheeseshop.python.org/pypi/zodbcode

Author: Zope Corporation and Contributors

Download: https://pypi.python.org/packages/source/z/zodbcode/zodbcode-3.4.0.tar.gz

        The package seeks to allow Python code to be stored in the ZODB. The main
benefits are that this code can then be easily transferred to other servers
and be changed at run time.

Detailed Documentation

Persistent Modules

Document Overview

This document seeks to capture technical information about persistent modules
to guide and document their design.


These goals largely come from Zope 3.  It would be worth while considering
other applications.

- Persistent modules are used to support management of software using the

- Software can be updated using network clients, such as web browsers and
  file-synchonozation tools.

- Application-server clusters can be updated transactionally without requiring
  server restarts.

- Persistent modules leverage a familiar model, modules, for managing Python

- Persistent modules can be synchronized to a file-system using the Zope
  file-system synchronization framework.  Persistent modules are synchronized
  for purposes including:

  o Use of traditional tools such as editors and code-analysis tools

  o Revision control

  Ideally, the file-system representation would consist of a Python source

Use cases

- Create classes and functions that implement Zope 3 components.

  o Utility, Adapter, View, and service classes and factories.

  o Content components, which are typically persistent and/or

- Define interfaces, including schema

- Import classes, functions, and interfaces from other modules.

- Import classes, functions, and interfaces from other persistent objects. For
  example, an adapter registration object might have a direct reference to a
  persistent-module-defined class.

- Change module source

  - Changes are reflected in module state

  - Changes are reflected in objects imported into other modules.

- Synchronize modules with a file-system representation.

Edge cases


Fundamental dilema

Python modules were not designed to change at run time.  The source of a
Python module normally doesn't change while a Python program is running.
There is a crude reload tool that allows modules to be manually reloaded to
handle source changes.

Python modules contain mutable state.  A module has a dictionary that may be
mutated by application code. It may contain mutable data that is modified at
run time.  This is typeically used to implement global registries.

When a module is reloaded, it is reexecuted with a dictionary that includes
the results of the previous execution.

Programs using the ZODB may be said to have logical lifetimes that exceed the
lifetimes of individual processes. In addition, the program might exist as
multiple individual processes with overlapping run-times.

The lifetime of a persistent program is long enough that it is likely that
module source code will change during the life time of the program.


Should the state of a module be represented soley by the module source?

Consider the possibilities:

A. Module state is represented soley by it's source.

- This would be a departure from the behavior of standard Python modules.
  Standard Python modules retain a module dictionary that is not overwritten
  by reloads.  Python modules may be mutated from outside and may contain
  mutable data structures that are modified at run time.

  OTOH, a regular module's state is not persistent or shared accross

  For standard Python modules, one could view the module source as an
  expression of the initial state of the module. (This isn't quite right
  either, since some modules are written in such a way that they anticipate
  module reloads.)

- Deleting variables from a module's source that have been imported by other
  modules or objects will cause the imported values to become disconnected
  from the module's source.  Even if the variables are added back later, the
  previously-imported values will be disconnected.

  It is tempting to introduce a data