mal wrote: > > (except for the unicode object module, that is). >=20 > I don't think so... it's very new and the C API isn't > documented. great. I'll just pretend it doesn't exist. =20 > > so if nobody uses this, I'd rather change the unicodeobject.c > > file to use the new API directly... >=20 > 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 ;-) but of course... everything except the "ctype" info is loaded from PYD/SO's, just as before. the only difference is that the files are slightly smaller :-) -rw-r--r-- 1 500 everyone 443392 Jul 15 18:55 ucnhash.pyd -rw-r--r-- 1 500 everyone 161280 Jul 15 18:53 uninames.pyd -rw-r--r-- 1 500 everyone 594944 Jul 11 23:03 unicodedata.pyd -rw-r--r-- 1 500 everyone 42496 Jul 15 15:25 unidata.pyd -rw-r--r-- 1 500 everyone 118329 Jul 13 21:01 unicodectype.obj -rw-r--r-- 1 500 everyone 10961 Jul 15 15:23 unictype.obj (names and sizes may change slightly before the final patch, but you get the idea). cheers /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