[Python-Dev] Fix import errors to have data

Phillip J. Eby pje at telecommunity.com
Wed Aug 4 18:16:37 CEST 2004


At 09:53 AM 8/4/04 -0400, Jim Fulton wrote:
>Phillip J. Eby wrote:
>>At 10:01 AM 8/2/04 -0400, Jim Fulton wrote:
>
>..
>
>>The point of my proposal is to make it possible *without* rewriting 
>>imports, in versions of Python from 2.2 up.
>
>Your proposal would, at least, require canges to the pickle framework.
>I imagine it would affect other serialization and persistence frameworks
>as well.

Actually, in the updated interface I've been discussing off-list with a few 
people, all that would happen is that you'd need to be explicit about what 
interpreter you use to do the unpickling, if you don't want it to be the 
current one.  E.g.:

    result = someInterpreter.call(somePickler.loads, data)

In a framework like ZODB, however, I would assume that if supporting 
multiple interpreters were desirable, one would change the persistent 
object ID to include a reference to the {bundle|parcel|product} that 
originated the object.

In any case, the implementation we're discussing (based on the C multiple 
interpreter API) should be completely transparent to end user code, to the 
extent that it should be possible to run two different versions of Zope 
side by side in the same process -- and that will probably make a nice 
"stress test" for the implementation when we're done with it.  :)

I hope that the end-product of our work will be an implementation of a 
Python-accessible API for interpreter management, and a PEP covering both 
that API and how to fix the most problematic aspects of the Python C API 
for multiple interpreters.  (Specifically, additions to the API to allow 
extensions to manage selected static data as interpreter-specific rather 
than global, and for ensuring that imports stay interpreter-local when 
execution crosses interpreter boundaries.)  I expect the fixes will be able 
to be used with versions of Python back to 2.2, which was the version that 
introduced the necessary base APIs for walking the interpreter and thread 
state chains.



More information about the Python-Dev mailing list