python24.dll and encodings ?

[Thomas Heller]

Bugs <dont at spam.me> writes:

> Thomas Heller wrote:
> [snip]
>> A PEP discussing the rationales would *really* be great.
>
> My whole impetus for this thread was to minimize the size of Python
> executables created with py2exe.  Right now they tend to be rather
> large, even for very small applications, as they include a bunch of
> unutilized Python functionality and/or encodings.

That was what I guessed.

> It would be nice to see a Python environment structure that is more
> desktop-application-friendly for applications that distribute the
> Python environment WITH the application (i.e. using py2exe).  Ideally,
> it would be nice to be able to distribute as minimal amount of the
> Python runtime environment as possible.

Before py2exe had the single-file option, the most common 'complaint'
was the large number of files it generated.  Now, the 'complaint' is
about the size of the executable.  (Historically, the change in
Python2.4 was done by Martin on my request, that was before the
single-file option in py2exe.  Plus, Python2.4 contains much more
encodings than 2.3 had.)

The PEP would probably have to find a balance between the number of
files and the size of a 'typical' py2exe built application.  Personally,
I don't care too much on either the file number and the files sizes
since I use inno setup for distributing the applications.

Technically, as far as py2exe is concerned, it would be nice if the zlib
module was a builtin module because it would be easier to bootstrap the
executable - for obvious reasons the zlib module cannot be loaded from a
(compressed) zipfile.  Unfortunately, this collides with Martin's
current policy to exclude extensions that need third party source code
from the python dll.

To summarize: Before someone requests a change to the builtin modules
list, a PEP would be needed to find the right balance.

Thomas