Thu, 1 Feb 2001 12:25:07 -0500
> > > > 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.
> > > 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.
> > 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:
> 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.
> 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
> OTOH, it may sometimes be necessary to explicitly use the
> direct and builtin import mechanism (e.g. during Python
This can be a valid reason, but not for cPickle...