Bugs <[EMAIL PROTECTED]> 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 -- http://mail.python.org/mailman/listinfo/python-list