[Import-sig] Re: Long-awaited imputil comments
Wed, 16 Feb 2000 15:43:54 -0500
> > I'm still worried about get_code() returning the code object
> > (or even a module, in the case of extensions). This means
> > that something like freeze might have to re-implement the
> > whole module searching -- first, it might want the source code
> > instead of the code object, and second, it might not want the
> > extension to be loaded at all!
If a freeze mechanism is analyzing source, then it needs
source, but I don't think that's necessary. Then only other
reason I can see for wanting source is if freeze is running with
one magic number, but the frozen code will run with another,
(to which I say "tough toenails, tootsie").
> You're asking for something that is impossible in practice. Consider the
> following code fragment:
> import my_imp_tools
> import qp_xml
> There is no way that you can create a freeze tool that will be able to
> manage this kind of scenario.
Sure. Dynamically replace the Importer in __bases__ with a
hacked one that doesn't affect sys.modules, grabs the code
object and analyzes byte code (like modulefinder does) to find
> I've frozen software for three different, shipping products. In all cases,
> I had to custom-build a freeze mechanism. Each time, there would be a list
> of "root" scripts, a set of false-positives to ignore, a set of missed
> modules to force inclusion, and a set of binary dependencies that couldn't
> be determined otherwise. I think the desire for a fully-automated module
> finder and freezer isn't fulfillable.
False-positives are unavoidable. Missed modules would be no
worse and probably better than today (since this scheme
would use the importer to trace the actions of the importer).