Now that Python 1.5.2 is here I need to upgrade from
1.5. We use Python internally and also ship Python
applications. Our environment is mixed PC's, Suns and
linux boxes. Our customers all have PC's. I always
find upgrades difficult, especially at customer sites since
we have no access, and have to depend on our Wise install
script.
I keep thinking how much easier this would be if the
Python library were built into the binary. I mean that
on PC's, the library were part of python15.dll for example.
No more worrys about a bad PYTHONPATH, the registry, my
1.5.2 binary using 1.5 libraries, the different ways all
this works on different platforms, etc. You just replace
python15.dll and you are at 1.5.2. Simple.
So I wrote some code. I don't consider it finished but
it works. It makes the Python library part of the binary.
1) The same code works for Unix and Windows. No "#ifdefs".
2) It uses the existing "frozen module" logic which has been
used as a way to ship Python main programs.
3) It extends frozen modules so that multiple frozen modules
can be linked together at run time. Currently there can only
be one frozen module.
4) Multiple frozen modules are built as regular Python extension
modules, and they install themselves when they are initialized.
You request them in Setup as usual. This was the only way I knew
to do the initialization in a portable way (suggestions?).
5) The C code is stupidly simple and very short. New code goes
into frozen.c, and few other changes are required.
6) There is a Python program in Tools/freeze which creates the Python
extension module with the Python libraries. It uses the new
"modulefinder.py" program. Thanks to whoever wrote it! It can
also be used to create other frozen modules, thus solving the
problem of how to make a frozen module.
7) The extension module need not be imported itself. It installs
the built-in frozen modules jusy by being initialized. But if
you import it, it has methods to turn the frozen modules on and
off, and to print the names in the modules.
So my questions are:
1) Am I the only one having trouble keeping the Python binary and
library files in sync?
2) Is any of this of interest? Should it be added to Python?
3) What features should be included? Does this do enough, too much?
4) Is this the right way to do it.
More technical details are available on request.
Jim Ahlstrom
1.5. We use Python internally and also ship Python
applications. Our environment is mixed PC's, Suns and
linux boxes. Our customers all have PC's. I always
find upgrades difficult, especially at customer sites since
we have no access, and have to depend on our Wise install
script.
I keep thinking how much easier this would be if the
Python library were built into the binary. I mean that
on PC's, the library were part of python15.dll for example.
No more worrys about a bad PYTHONPATH, the registry, my
1.5.2 binary using 1.5 libraries, the different ways all
this works on different platforms, etc. You just replace
python15.dll and you are at 1.5.2. Simple.
So I wrote some code. I don't consider it finished but
it works. It makes the Python library part of the binary.
1) The same code works for Unix and Windows. No "#ifdefs".
2) It uses the existing "frozen module" logic which has been
used as a way to ship Python main programs.
3) It extends frozen modules so that multiple frozen modules
can be linked together at run time. Currently there can only
be one frozen module.
4) Multiple frozen modules are built as regular Python extension
modules, and they install themselves when they are initialized.
You request them in Setup as usual. This was the only way I knew
to do the initialization in a portable way (suggestions?).
5) The C code is stupidly simple and very short. New code goes
into frozen.c, and few other changes are required.
6) There is a Python program in Tools/freeze which creates the Python
extension module with the Python libraries. It uses the new
"modulefinder.py" program. Thanks to whoever wrote it! It can
also be used to create other frozen modules, thus solving the
problem of how to make a frozen module.
7) The extension module need not be imported itself. It installs
the built-in frozen modules jusy by being initialized. But if
you import it, it has methods to turn the frozen modules on and
off, and to print the names in the modules.
So my questions are:
1) Am I the only one having trouble keeping the Python binary and
library files in sync?
2) Is any of this of interest? Should it be added to Python?
3) What features should be included? Does this do enough, too much?
4) Is this the right way to do it.
More technical details are available on request.
Jim Ahlstrom