(original) (raw)
On Fri, Feb 20, 2009 at 12:53, Aahz <aahz@pythoncraft.com> wrote:
If you define it, yes.
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
# \_pickleOn Fri, Feb 20, 2009, Brett Cannon wrote:
> On Fri, Feb 20, 2009 at 12:37, Brett Cannon <brett@python.org> wrote:
>> On Fri, Feb 20, 2009 at 12:31, Daniel Stutzbach <
>> daniel@stutzbachenterprises.com> wrote:
>>>
>>> A slight change would make it work for modules where only key functionsDoesn't \_\_all\_\_ control this?
>>> have been rewritten. For example, pickle.py could read:
>>>
>>> from \_pypickle import \*
>>> try: from \_pickle import \*
>>> except ImportError: pass
>>
>> True, although that still suffers from the problem of overwriting things
>> like \_\_name\_\_, \_\_file\_\_, etc.
>
> Actually, I take that back; the IMPORT\_STAR opcode doesn't pull in anything
> starting with an underscore. So while this alleviates the worry above, it
> does mean that anything that gets rewritten needs to have a name that does
> not lead with an underscore for this to work. Is that really an acceptable
> compromise for a simple solution like this?
If you define it, yes.
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
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.
-Brett