On 07:07 pm, brett at python.org wrote: >On Sat, Feb 21, 2009 at 09:17, Jean-Paul Calderone ><exarkun at 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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4