[Python-Dev] Choosing a best practice solution for Python/extension modules

Michael Foord fuzzyman at voidspace.org.uk
Sun Feb 22 19:29:11 CET 2009


Steven Bethard wrote:
> On Fri, Feb 20, 2009 at 1:45 PM, Brett Cannon <brett at 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.

Michael

-- 
http://www.ironpythoninaction.com/



More information about the Python-Dev mailing list