(original) (raw)

Steven Bethard wrote:

On Fri, Feb 20, 2009 at 1:45 PM, Brett Cannon <brett@python.org> wrote:
 

But there is another issue with this: the pure Python code will never call
the extension code because the globals will be bound to \_pypickle and not
\_pickle. So if you have something like::

 # \_pypickle
 def A(): return \_B()
 def \_B(): return -13

 # \_pickle
 def \_B(): return 42

 # pickle
 from \_pypickle import \*
 try: from \_pickle import \*
 except ImportError: pass

If you import pickle and call pickle.A() you will get -13 which is not what
you are after.
   

Maybe I've missed this and someone else already suggested it, but
couldn't we provide a (probably C-coded) function
\`\`replace\_globals(module, globals)\`\` that would, say, replace the
globals in \_pypickle with the globals in pickle? Then you could write
something like::

   from \_pypickle import \*
   try:
       from \_pickle import \*
       module = \_\_import\_\_('\_pickle')
   except ImportError:
       module = \_\_import\_\_('\_pypickle')
   replace\_globals(module, globals())

Steve
 

Swapping out module globals seems to be a backwards way to do things to me.

Why not have one set of tests that test the low level APIs (identical tests whether they are written in C or Python) - and as they live in their own module are easy to test in isolation. And then a separate set of tests for the higher level APIs, which can even mock out the low level APIs they use. There shouldn't be any need for switching out objects in the scope of the lower level APIs - that seems like a design smell to me.