[Python-Dev] Re: [I18n-sig] Planned updates for cjkcodecs before 2.4a1

[Hye-Shik Chang]

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