(except for the unicode object module, that is). 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... </F>
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