[Import-sig] Imputil

Gordon McMillan gmcm@hypernet.com
Thu, 1 Feb 2001 12:25:07 -0500


[Thomas Heller]
> > > > cPickle uses PyImport_ImportModule(name) instead of
> > > > PyImport_Import(name) which would then in turn use the
> > > > import hook function. cPickle imports copy_reg, string,
> > > > types.
[MAL]
> > > The various uses of PyImport_ImportModule() in cPickle are
> > > only used for standard modules -- I don't think these pose
> > > much of a problem w/r to imputil and other import hooks,
> > > since these are either available using the standard import
> > > mechanism or as frozen modules compiled into the core.
[TH]
> > No, these are exactly the problem (maybe only my problem?). If
> > the standard import mechanism is NOT available (think of
> > Gordon's installer or my py2exe project) because everything is
> > loaded from an archive, importing cPickle will fail if you do:
[MAL]
> Perhaps you should add some "boot" code to py2exe then or
> freeze the standard lib into the interpreter itself ?!
> (mxCGIPython works this way.)

Freezing them all in bloats the exe by a meg or more. Putting 
them in a compressed archive gets it down to 500K or so. 
Just archiving the ones you need makes it even smaller.
[MAL]
> Changing cPickle.c doesn't help here: the PyImport_ImportModule()
> API would have to be made __import__ aware to fix this problem
> because a lot of Python code including the core itself uses this
> more direct import API.

PyImport_Import() is already __import__ aware. Other than a 
(misguided) thirst for speed there's very few excuses for using 
PyImport_ImportModule() instead.
 
> OTOH, it may sometimes be necessary to explicitly use the
> direct and builtin import mechanism (e.g. during Python
> startup)... 

This can be a valid reason, but not for cPickle...

- Gordon