<br><br><div class="gmail_quote">On Sun, Feb 22, 2009 at 10:29, Michael Foord <span dir="ltr"><<a href="mailto:fuzzyman@voidspace.org.uk">fuzzyman@voidspace.org.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div></div><div class="Wj3C7c">Steven Bethard wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Fri, Feb 20, 2009 at 1:45 PM, Brett Cannon <<a href="mailto:brett@python.org" target="_blank">brett@python.org</a>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
But there is another issue with this: the pure Python code will never call<br>
the extension code because the globals will be bound to _pypickle and not<br>
_pickle. So if you have something like::<br>
<br>
# _pypickle<br>
def A(): return _B()<br>
def _B(): return -13<br>
<br>
# _pickle<br>
def _B(): return 42<br>
<br>
# pickle<br>
from _pypickle import *<br>
try: from _pickle import *<br>
except ImportError: pass<br>
<br>
If you import pickle and call pickle.A() you will get -13 which is not what<br>
you are after.<br>
<br>
</blockquote>
<br>
Maybe I've missed this and someone else already suggested it, but<br>
couldn't we provide a (probably C-coded) function<br>
``replace_globals(module, globals)`` that would, say, replace the<br>
globals in _pypickle with the globals in pickle? Then you could write<br>
something like::<br>
<br>
from _pypickle import *<br>
try:<br>
from _pickle import *<br>
module = __import__('_pickle')<br>
except ImportError:<br>
module = __import__('_pypickle')<br>
replace_globals(module, globals())<br>
<br>
Steve<br>
<br>
</blockquote>
<br></div></div>
Swapping out module globals seems to be a backwards way to do things to me.</blockquote><div><br>I agree; I would rather muck with sys.modules at that point.<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
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.</blockquote>
<div><br> That's possible. As I have said, my only worry with the separate py/extension module approach is that any time someone wants to do an extension version of something the Python code will need to be moved.<br>
<br>But at this point I am honestly burning out on this topic (got a lot on my plate right now) so I am going to let somebody else lead this to the finish line. =)<br><br>-Brett<br></div></div>