[me]
Perhaps it would make sense to move the Unicode database on the Python side (write it in Python)? Or init the database dynamically in the unicodedata module on import? It's quite big, so if it's possible to avoid the static declaration (and if the unicodata module is enabled by default), I'd vote for a dynamic initialization of the database from reference (Python ?) file(s).
[Marc-Andre]
The unicodedatabase module contains the Unicode database as static C data - this makes it shareable among (Python) processes.
The static data is shared if the module is a shared object (.so). If unicodedata is not a .so, then you'll have a seperate copy of the database in each process.
Python modules don't provide this feature: instead a dictionary would have to be built on import which would increase the heap size considerably. Those dicts would *not* be shareable.
I haven't mentioned dicts, have I? I suggested that the entries in the C version of the database be rewritten in Python (or a text file) The unicodedata module would, in it's init function, allocate memory for the database and would populate it before returning "import okay" to Python -- this is one way to init the db dynamically, among others. As to sharing the database among different processes, this is a classic IPC pb, which has nothing to do with the static C declaration of the db. Or, hmmm, one of us is royally confused <wink>. -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252