Hi, I have been working with the Tools/freeze/freeze.py etc. utilities in order to build a Python binary with part of the Python library built in. I found out you-all have been working on this. But AFAIK we are not there yet. I see that using freeze.py will create a binary Python with the libs included in the frozen module. But: 1) The "script" argument to freeze.py is not optional. Some module is always frozen with the name __main__ and so it is always executed when Python starts up. This makes it impossible to create a python15.dll (or python15.so) which is general-purpose. That is, a shared binary Python with libraries but not a main program built in. Since the Python interpreter and libs must use exactly the same version, it is useful to link them together. 2) There is only one frozen module allowed, so no further use of frozen modules is possible. The frozen feature has been devoted to the Python libraries. This makes it impossible to make a python15.dll which can be used with a variety of python.exe programs with further frozen modules. Unix translation: A python15.so shared library for use with further python main programs containing frozen modules. I have code which solves both problems. But perhaps I have not understood Tools/freeze, and there is already a way to do this? I see there is a function PyImport_ExtendInittab() in import.c which adds entries to the table of built-in modules, which is sort of analogous to (2), but that this function is unused. (My code uses a different method.) Please let me know what you think. Is this useful enough to be added to Python? Or is it already there? Jim Ahlstrom
[Jim laments about freeze and some good enhancements he whipped up] Here is my personal take on this. It is formed simply by working with freeze, at one stage attempting to generate interest in helping extend freeze, and watching what other people do when faced with a similar problem. I get the impression freeze is dieing. It is dieing in favour of techniques that avoid requiring a C compiler and allow an even more generic concept of where "frozen" code can come from. Although avoiding the C compiler is particularly attractive on Windows (where users can't be assumed to have one), it offers a number of other benefits on all platforms. Specifically, Greg Stien and Gordon McMillan (and plenty of people before them :-) seem to have what is considered "state of the art" in where this is heading. But "where it is heading" is the rub. Freeze is still well ahead in a number of significant areas. The ideas you describe are definately worth-while, but freeze works OK for me now - so whenever I next get a decent block of time to play with this stuff some more, I am likely to focus on these other efforts other than freeze. I dont think you will find many people arguing either way on this. My only comment is that re Point 2: PyImport_ExtendInittab() is indeed able to give the functionality you describe. Each seperate frozen package can call this function to add its frozen modules. So this means your patch for this should be unnecessary (or at least slightly different to take advantage of this). Re point 1: This is possible (or nearly :) for Windows freeze builds, but AFAIK not for Unix builds, so this definately seems worthwhile. And-it-still-needs-more-hacks-to-complete-COM-support-ly, Mark.
[Hmm.... Jim looks at clock and wonders what Mark is doing down in Australia in the middle of the night...] Mark Hammond wrote:
I get the impression freeze is dieing. It is dieing in favour of techniques that avoid requiring a C compiler and allow an even more generic concept of where "frozen" code can come from. Although avoiding the C compiler is particularly attractive on Windows (where users can't be assumed to have one), it offers a number of other benefits on all platforms. Specifically, Greg Stien and Gordon McMillan (and plenty of people before them :-) seem to have what is considered "state of the art" in where this is heading.
I don't know of techniques which aren't Windows specific. Greg?? Gordon??
I dont think you will find many people arguing either way on this. My only comment is that re Point 2: PyImport_ExtendInittab() is indeed able to give the functionality you describe.
I don't think so. It adds to the list of available compiled-in modules, so that were they imported, they would be available for import. But the problem is how to get them imported. In particular, "__main__" would never be called unless it were explicitly a frozen module. The list of frozen modules PyImport_FrozenModules is not the same as PyImport_Inittab. Actually, I am not sure how to solve this even in my current code, except in a Windows-specific way.
Re point 1: This is possible (or nearly :) for Windows freeze builds, but AFAIK not for Unix builds, so this definately seems worthwhile.
Jim Ahlstrom
participants (2)
-
James C. Ahlstrom -
Mark Hammond