<br><br><div class="gmail_quote">On Sun, Feb 22, 2009 at 22:41, Aahz <span dir="ltr"><<a href="mailto:aahz@pythoncraft.com">aahz@pythoncraft.com</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">On Sun, Feb 22, 2009, Brett Cannon wrote:<br>
> On Sat, Feb 21, 2009 at 20:12, Aahz <<a href="mailto:aahz@pythoncraft.com">aahz@pythoncraft.com</a>> wrote:<br>
>> On Sat, Feb 21, 2009, Brett Cannon wrote:<br>
>>> On Sat, Feb 21, 2009 at 15:46, Aahz <<a href="mailto:aahz@pythoncraft.com">aahz@pythoncraft.com</a>> wrote:<br>
>>>> On Sat, Feb 21, 2009, Brett Cannon wrote:<br>
>>>>><br>
>>>>> I am seeing two approaches emerging. One is where pickle contains all<br>
>>>>> Python code and then uses something like use_extension to make sure<br>
>>>>> the original Python objects are still reachable at some point. This<br>
>>>>> has the drawback that you have to use some function to make the<br>
>>>>> extensions happen and there is some extra object storage.<br>
>>>>><br>
>>>>> The other approach is having pickle contain code known not to<br>
>>>>> be overridden by anyone, import _pypickle for stuff that may be<br>
>>>>> overridden, and then import _pickle for whatever is available. This<br>
>>>>> approach has the perk of using a standard practice for how to pull in<br>
>>>>> different implementation. But the drawback, thanks to how globals are<br>
>>>>> bound, is that any code pulled in from _pickle/_pypickle will not be<br>
>>>>> able to call into other optimized code; it's a take or leave it once<br>
>>>>> the call chain enters one of those modules as they will always call<br>
>>>>> the implementations in the module they originate from.<br>
>>>><br>
>>>> To what extent do we care about being able to select Python-only on a<br>
>>>> per-module basis, particularly in the face of threaded imports? That<br>
>> is,<br>
>>>> we could have a sys.python_only attribute that gets checked on import.<br>
>>>> That's simple and direct, and even allows per-module switching if the<br>
>>>> application really cares and import doesn't need to worry about threads.<br>
>>>><br>
>>>> Alternatively, sys.python_only could be a set, but that gets ugly about<br>
>>>> setting from the application. (The module checks to see whether it's<br>
>>>> listed in sys.python_only.)<br>
>>>><br>
>>>> Maybe we should move this discussion to python-ideas for now to kick<br>
>>>> around really oddball suggestions?<br>
>>><br>
>>> This is all about testing. If a change is made to some extension code it<br>
>>> should be mirrored in the Python code and vice-versa.<br>
>><br>
>> Okay, I don't see how that is a response to my suggestion -- I can<br>
>> imagine that someone might want to test a combination of pure-Python and<br>
>> binary libraries.<br>
><br>
> I don't want to move it because this isn't some idea for a new feature that<br>
> may or may not be useful; this isn't an "idea", it's needed.<br>
<br>
</div></div>That's fine, but what about my idea of using sys.python_only?</blockquote><div><br>But what is it supposed to represent? That only pure Python modules get imported? What if the module depends on another module that is an extension module?<br>
<br>-Brett <br></div></div><br>