[Stackless] Fwd: deepcopying (pickling) channels

Christian Tismer tismer at stackless.com
Sun Oct 27 23:18:39 CET 2013

On 25.10.13 16:55, John Ehresman wrote:
> On 10/24/13 8:20 PM, Christian Tismer wrote:
>> I looked into the old CVS sources. The code is different, but has the 
>> same
>> principle:
>>> /* Get the __import__ function from the builtins */ if
>>> (PyDict_Check(builtins)) { import = PyObject_GetItem(builtins,
>>> import_str); if (import == NULL) PyErr_SetObject(PyExc_KeyError,
>>> import_str); } else import = PyObject_GetAttr(builtins, import_str);
>>> if (import == NULL) goto err; tup = Py_BuildValue("(O(s))", import,
>>> name);
>> Richard's version uses a slightly different way, but also grabs 
>> __import__
>> from the builtins of the interpreter.
> It worries me a bit that this is only done for __import__ and not for 
> the other builtins; it suggests to me that there is a reason for 
> grabbing __import__
>> And the problem is that I am giving that function back, which is your
>> hook, right?
> The immediate issue is that pickle is failing to save globals because 
> of the value of __import__.  That is probably fixable, but I'm trying 
> to figure out when the saved globals is used -- what happens when a 
> pickle created when the debugger is running is unpickled when the 
> debugger isn't running?  What happens in the reverse case?

"Monk" tismer says:
Here is what happened:

Stackless does a lot to avoid pickling module dicts. For that reason,
there is extra support for the case when pickling of a module dict happens.

Test code:
import pickle

def func(): pass

class Test0(object):
     def __init__(self):
         self.func = func

class Test1(object):
     def __init__(self):
         self.func = lambda s: 0

In Test0, func is an entry of module __main__. The __dict__ of __main__
is found as the dict of __main__, and the support machinery works.

In Test1, func is an anonymous lambda, and its func_globals dict must be
pickled since it is not reachable from the module globals.

Stackless grabs __import__ from __builtin__, in order to get __main__,
then builds a reconstructor which can build the lambda and assign it
to __main__.

But now __import__ must be resolved. In the normal case, with no Wing
running, this is a known __builtin__ member and we are done.

When Wing IDE is active, __import__ is actually function wingdb_import_hook
of module tdbgtracer27stacklessx64, and that cannot be imported.

So my guess of the solution is this:

Let wingdb_import_hook report "__builtin__" as its module and 
'__import__' as
its name, and you are fine.

cheers -- Chris

Christian Tismer             :^)   <mailto:tismer at stackless.com>
Software Consulting          :     Have a break! Take a ride on Python's
Karl-Liebknecht-Str. 121     :    *Starship* http://starship.python.net/
14482 Potsdam                :     PGP key -> http://pgp.uni-mainz.de
phone +49 173 24 18 776  fax +49 (30) 700143-0023
PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
       whom do you want to sponsor today?   http://www.stackless.com/

More information about the Stackless mailing list