Python does not play well with others

[Paul Rubin]

"Graham Dumpleton" <grahamd at dscpl.com.au> writes:
> Yes, these per VirtualHost interpreter instances will only be created
> on demand in the child process when a request arrives which
> necessitates it be created and so there is some first time setup for
> that specific interpreter instance at that point, but the main Python
> initialisation has already occurred so this is minor. 

Well ok, but what if each of those interpreters wants to load, say,
the cookie module?  Do you have separate copies of the cookie module
in each interpreter?  Does each one take the overhead of loading the
cookie module?  It would be neat if there was a way of including
frequently used modules in the shared text segment of the
interpreters, as created during the initial build process.  GNU Emacs
used to do something like that with a contraption called "unexec" (it
could dump out parts of its data segment into a pure (shared)
executable that you could then run without the overhead of loading all
those modules) but the capability went away as computers got faster
and it became less common to have a lot of Emacs instances weighing
down timesharing systems.  Maybe it's time for a revival of those
techniques.