[Import-sig] Re: Long-awaited imputil comments

Gordon McMillan gmcm@hypernet.com
Wed, 16 Feb 2000 15:43:54 -0500


[Guido]
> >         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").
 
[Greg]
> You're asking for something that is impossible in practice. Consider the
> following code fragment:
> 
> ------------------------
> import my_imp_tools
> my_imp_tools.HTTPImporter("http://www.lyra.org/greg/python/")
> 
> 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 
further imports.

> 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).
 


- Gordon