• BugList

This is a page to collect known issues to be fixed in future versions:

Issues

Page module mixin corrupts sys.modules

Using the following page structure on disk the page module mixin imports both test.py pages as a 'test' module, i.e. sys.mocules['test'] is used for both.

pages/
    list.py
    a/
        list.py
    b/
        list.py

This causes problems in the application as only one of the page modules can exist in sys.modules. It's actually the latest page module to be loaded that wins the fight. It's is quite likely (although unproven) that page modules can also replace real Python modules i.e. if the page module was called callendar.py it may replace Python 2.3's standard calendar module.

There are a few solutions, each of which has potential problems:

1. Force page modules to be in a package hierarchy. Existing applications would need to be changed for this although it's probably only a matter of adding init.py in various places. This still leaves the possibility that page modules not inside a package (i.e. the first list.py above) could replace sys.modules entries.

2. Use a more complex module import scheme that fakes a top level package (say albatrosspages) and fakes a package/module name, i.e. list.py becomes albatrosspages.list, a/list.py becomes albatrosspages.a.list etc. Should we mess around Python's module machinery in this way though?

3. Don't import page modules, use execfile() instead. This is the cleanest solution but means that any supporting classes defined in a page module that are stored in the session (or just pickled), i.e. tree nodes, must be moved to a real module. execfile() also does not compile modules so there will be a decrease in performance.