On Wed, Jun 16, 2004 at 08:16:52PM +0900, Hye-Shik Chang wrote: > On Wed, Jun 16, 2004 at 11:33:59AM +0200, M.-A. Lemburg wrote: > > Hye-Shik Chang wrote: > [snip] > > >2. Merge two or three simliar C codecs into one. We have one C > > > codec for every each python codecs currently. I have got an > > > idea to merge them into several similar groups and many common > > > part of .so binaries will be saved: > > > > +1, but why not put all Japanese codecs into one module and > > dito for the Korean and Chinese ones ? > > > > Note that todays OS linkers will only mmap those pieces > > of code into the process memory that are actually needed > > by the application, so even though the size of the modules > > increases, the application process memory foot-print is > > likely not to increase. > > Okay. But how about embedded, freezed environments or statically > compiled into python by uncommenting from Modules/Setup? If somebody > need to support only legacy Japanese encodings, he will want to > include a legacy mapping(70K) but will not want JIS X 0213(85K) and > KS X 1001, GB2312 mappings(200K, for iso-2022-jp-2). And he may > want to save spaces by just erasing files. In fact, I don't know > how real Japanese developers use but just guessed it. :) > Aah. While I'm taking shower, I found that a problem on iso-2022-jp-2 can be resolved by make codecs to load mapping tables on demand. (they're loading mappings in init function currently.) I agree in incorporating all CJK codecs to each per-language codec collection modules. Thanks for the comments! Hye-Shik -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 187 bytes Desc: not available Url : http://mail.python.org/pipermail/python-dev/attachments/20040616/7d4bf748/attachment.bin
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