Fredrik Lundh wrote: > > mal wrote: > > > 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 ;-) > > 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). Cool :-) (I'd suggest keeping the original names, BTW) -- 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