Mark writes in private email:

  "Modules listed in the registry was a dumb idea.  This whole scheme
  can die.  AFAIK, no one in the world uses it (including win32all
  since the last build)."

(See also SF #643711)

per PEP 291 (although there are currently string methods used).

This patch makes it compatible with 2.2, at least, by detecting
universal newline support.

Fixes SF # 637835.

Use universal newline support when opening a file for freezing.

Pass co_freevars and co_cellvars to new.code().
Will backport.

The file itself still mentions Python 1.5.1,
so it might need further updates.

(with one small bugfix in bgen/bgen/scantools.py)

This replaces string module functions with string methods
for the stuff in the Tools directory. Several uses of
string.letters etc. are still remaining.

From patch: [ 574532 ] Update freeze to use zlib 1.1.4

extension.

Fixes SF 564840.

Fixed a few compiler warnings.

freeze.py now produces binaries which can import shared
modules (unlike before).

(With slight cosmetic improvements to shorten lines and a grammar fix
to a docstring.)

This addes -X and -E options to freeze.  From the docstring:

-X module     Like -x, except the module can never be imported by
              the frozen binary.

-E:           Freeze will fail if any modules can't be found (that
              were not excluded using -x or -X).

directives, which is the role of CPPFLAGS.  Closes SF patch #414991.

and Setup.

  This patch was developed primarily to reduce the size of the
  frozen binary.  It is particularly useful when freezing for 'small'
  platforms, such as Palm OS, where you really want to save that
  last miserable byte.

  A limitation of this patch is that it does not provide any feedback
  about the replacements being made.  As the path matching
  is case-sensitive this may lead to unexpected behaviour for DOS
  and Windows people, eg
      > freeze.py -r C:\Python\Lib\=py\ goats.py
  should probably be:
      > freeze.py -r c:\python\lib\=py\ goats.py

the re package rather than the obsolete regex.

crashed on an assert.

closes patch #100956

comments, docstrings or error messages. I fixed two minor things in
test_winreg.py ("didn't" -> "Didn't" and "Didnt" -> "Didn't").

There is a minor style issue involved: Guido seems to have preferred English
grammar (behaviour, honour) in a couple places. This patch changes that to
American, which is the more prominent style in the source. I prefer English
myself, so if English is preferred, I'd be happy to supply a patch myself ;)

automatically finding (most of) the standard PYD extensions, and to
remove the hardcoded Python version.

Fix for problem with freeze when both "-m" and "-s service" options
are used.

(Blessed by MarkH)

Bad % formatting.

cmp is not used in freeze, but is imported anyway.  What's worse, cmp
is no longer in the library, so freeze won't work like this.

Sometimes there's no parent, so don't try to get its __name__.

Added some declarations to shut up compiler.

around external decls.

"""
When there are additional Setup files, specified by -e option of freeze,
checkextenstions.py assumes that *.o, *.a, -Lpath, and -Rpath are all
relative to where the Setup file is. select() inserts the path to the
Setup file to make them absolute. However, the assumption is not true.
There are cases that absolute paths are specified for them. The inserted
prefix, by select(), results in error.

The following fix check for absolute paths. The assumption is: an
absolute path begins with either '/' or '$'. In the latter case, it is
from the environmental variable. (Variables defined locally in the Setup
file have already been handled by expandvars())
"""

My version of the patch has been verified by Charles Waldman (a
colleague of Chih-Hao).

Toby writes:

winmakemakefile.py tries to allow for spaces in the python install
path, by adding quotes around the appropriate filenames. It doesn't
quite get this correct; sometimes the quotes end up in the middle of
the path.

Microsoft's NMAKE version 6.0 is happy with this (!!!!)  unless there
is also a space in the name. I guess most users of freeze on windows
do not use the same path as the binary distribution.

I've tested the following changes on systems with and without a space
in the path.

   Under Windows, python freeze.py -o hello hello.py
   creates all the correct files in the hello subdirectory, but the
   Makefile has the directory prefix in it for frozen_extensions.c
   nmake fails because it tries to locate hello/frozen_extensions.c

(His fix adds a call to os.path.basename() in the appropriate place.)