This is a page to collect known issues to be fixed in future versions:
Page module mixin corrupts sys.modules
Note: this was fixed in version 1.20
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:
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.
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?
- 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.
Support for unicode/utf-8
AndrewMc has an experimental branch on the CVS tree that supports Unicode, although it's slipped behind the HEAD in several important respects. It hasn't been integrated because it will cause some existing applications to break, although it works well for applications that need internationalised text. It also results in a 30% increase in template execution time. There is also no entirely satisfactory answer to form submissions (current generation browsers don't tell you the encoding they used). In Py3k, the 8-bit str type will be dropped, and unicode will become the standard string - so these issues will need to be resolved by then.
Note that, at least partially, you can get away with encoding text as utf-8 prior to sending it to albatross, and a number of applications are exploiting this in production. The above refers to end-to-end unicode support.