Fredrik Lundh wrote: > > (except for the unicode object module, that is). I don't think so... it's very new and the C API isn't documented. > as I've mentioned earlier, I'm working on an alternative unicode > database, which includes a ucnhash replacement. > > my first thought was to emulate the existing api, but it has two > small problems: > > -- it returns pointers into the database. this means that you > cannot compress the names at all, if you want to be thread- > safe (which you have to be, in this case). > > -- it exposes low-level implementation details, such as the hash > table size, etc. I'm not sure if I can emulate that in any sane > way under the new database design. > > so if nobody uses this, I'd rather change the unicodeobject.c > file to use the new API directly... Please don't drop the idea of an on-demand loadable module though. The current design used by Bill Tutt is to load the ucnhash module (which contains the mappings) only when it is needed -- most code won't need it. BTW, does you database use the on-demand loading feature ? I don't think that having the Unicode database linked statically in the Python interpreter is a good idea -- at least not until Unicode takes over ;-) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4