Shrinky-dink Python (also, non-Unicode Python build is broken)

[Giovanni Bajo]

Larry Hastings wrote:

> First and foremost: turning off Py_USING_UNICODE *breaks the build*
> on Windows.

Probably nobody does that nowadays. My own feeling (but I don't have numbers
for backing it up) is that the biggest size in the .DLL is represented by
things like the CJK codecs (which are about 800k). I don't think you're
gaining that much by trying to remove unicode support at all, especially
since (as you noticed) it's going to be maintenance headhache.

> Second of all, the dumb-as-a-bag-of-rocks Windows linker (at least
> the one used by VC++ under MSVS .Net 2003) *links in unused static
> symbols*.  If I want to excise the code for a module, it is not
> sufficient to comment-out the relevant _inittab line in config.c.
> Nor does it help if I comment out the "extern" prototype for the
> init function.  As far as I can tell, the only way to *really* get
> rid of a module, including all its static functions and static data,
> is to actually *remove all the code* (with comments, or #if, or
> whatnot).  What a nosebleed, huh?

This is off-topic here, but MSVC linker *can* strip unused symbols, of
course. Look into /OPT:NOREF.

> So in order to build my *really* minimal python24.dll, I have to hack
> up the source something fierce.  It would be pleasant if the Python
> source code provided an easy facility for turning off modules at
> compile-time.  I would be happy to propose something / write a PEP
> / submit patches to do such a thing, if there is a chance that such
> a thing could make it into the official Python source.  However, I
> realize that this has terribly limited appeal; that, and the fact
> that Python releases are infrequent, makes me think it's not a
> terrible hardship if I had to re-hack up each new Python release
> by hand.

You're not the only one complaining about the size of Python .DLL: also
people developing self-contained programs with tools like PyInstaller or
py2exe (that is, programs which are supposed to run without Python
installed) are affected by the lack of a clear policy.

I myself complained before, especially after Python 2.4 got those ginormous
CJK codecs within its standard DLL, you can look for the thread in Google.
The bottom line of that discussion was:

- The policy about what must be linked within python .dll and what must be
kept outside should be proposed as a PEP, and it should provide guidelines
to be applied also for future modules.
- There will be some opposition to the obvious policy of "keeping the bare
minimum inside the DLL" because of inefficiencies in the Python build
system. Specifically, I was told that maintaining modules outside the DLL
instead of inside the DLL is more burdesome for some reason (which I have
not investigated), but surely, with a good build system, switching either
configuration setting should be the matter of changing a single word in a
single place, with no code changes required.

Personally, I could find some time to write up a PEP, but surely not to pick
up a lengthy discussion nor to improve the build system myself. Hence, I
mostly decided to give up for now and stick with recompiling Python myself.
The policy I'd propose is that the DLL should contain the minimum set of
modules needed to run the following Python program:

-------------------
print "hello world"
-------------------

There's probably some specific exception I'm not aware of, but you get the
big picture.
-- 
Giovanni Bajo