On 07:07 pm, br...@python.org wrote:
On Sat, Feb 21, 2009 at 09:17, Jean-Paul Calderone
<exar...@divmod.com>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
This is really the same as any other high-level/low-level
library split. It doesn't matter that in this case, one
low-level implementation is provided as an extension module.
Importing the low-level APIs from another module and then
using them to implement high-level APIs is a pretty common,
simple, well-understood technique which is quite applicable
here.
But that doesn't provide a clear way, short of screwing with
sys.modules, to
get at just the pure Python implementation for testing when the
extensions
are also present. The key point in trying to figure this out is to
facilitate testing since the standard library already uses the import *
trick in a couple of places.
You don't have to screw with sys.modules. The way I would deal with
testing this particular interaction would be a setUp that replaces
pickle._A with _pypickle._A, and a tearDown that restores the original
one.
Twisted's TestCase has specific support for this. You would spell it
like this:
import _pypickle
# ...
testCase.patch(pickle, '_A', _pypickle._A)
You can read more about this method here:
http://python.net/crew/mwh/apidocs/twisted.trial.unittest.TestCase.html#patch
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
