[I18n-sig] Planned updates for cjkcodecs before 2.4a1
perky at i18n.org
Wed Jun 16 07:35:18 EDT 2004
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:
> > >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!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 187 bytes
Desc: not available
Url : http://mail.python.org/pipermail/i18n-sig/attachments/20040616/7d4bf748/attachment.bin
More information about the I18n-sig