On Sun, Feb 22, 2009 at 10:29, Michael Foord <fuzzy...@voidspace.org.uk>wrote:
> Steven Bethard wrote:
>
>> On Fri, Feb 20, 2009 at 1:45 PM, Brett Cannon <br...@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.
I agree; I would rather muck with sys.modules at that point.
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.
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.
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. =)
-Brett
_______________________________________________
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
