This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author giovannibajo
Recipients amaury.forgeotdarc, giovannibajo, hyeshik.chang, kcwu, lemburg, loewis
Date 2008-02-16.18:21:23
SpamBayes Score 0.00070415257
Marked as misclassified No
Message-id <1203186085.21.0.0710341852062.issue2066@psf.upfronthosting.co.za>
In-reply-to
Content
Making the standard Windows Python DLL larger is not only a problem of
disk size: it will make all packages produced by PyInstaller or py2exe
larger, and that means lots of wasted bandwidth.

I see that MvL is still -1 on simply splitting CJK codecs out, and vetos
it by asking for a generalization work of insane proportion (a
hard-to-define PEP, an entirely new build system for Windows, etc.).

I understand (and *agree*) that having a general rule would be a much
superior solution, but CJK is already almost 50% of the python.dll, so
it *is* already a special case by any means. And special cases like
these  could be handled with special-case decisions.

Thus, I still strongly disagree with MvL and would like CJK be split out
 of python.dll as soon as possible. I would not really ask this for any
other modules but CJK, and understand that further actions would really
require a PEP and a new build system for Windows.

So, I ask again MvL to soften his position and reconsider the CJK
splitting in all its singularity. Please!

(in case it's not clear, I would prepare a patch to split CJK out anyday
if there were hopes that it gets accepted)
History
Date User Action Args
2008-02-16 18:21:25giovannibajosetspambayes_score: 0.000704153 -> 0.00070415257
recipients: + giovannibajo, lemburg, loewis, amaury.forgeotdarc, hyeshik.chang, kcwu
2008-02-16 18:21:25giovannibajosetspambayes_score: 0.000704153 -> 0.000704153
messageid: <1203186085.21.0.0710341852062.issue2066@psf.upfronthosting.co.za>
2008-02-16 18:21:24giovannibajolinkissue2066 messages
2008-02-16 18:21:23giovannibajocreate