[Python-Dev] Choosing a best practice solution for Python/extension modules (original) (raw)

Brett Cannon brett at python.org
Fri Feb 20 22:45:26 CET 2009

On Fri, Feb 20, 2009 at 12:53, Aahz <aahz at pythoncraft.com> wrote:

On Fri, Feb 20, 2009, Brett Cannon wrote: > On Fri, Feb 20, 2009 at 12:37, Brett Cannon <brett at python.org> wrote: >> On Fri, Feb 20, 2009 at 12:31, Daniel Stutzbach <_ _>> daniel at stutzbachenterprises.com> wrote: >>> >>> A slight change would make it work for modules where only key functions >>> 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 IMPORTSTAR 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?

Doesn't all control 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

_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.

-Brett -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20090220/38243ef3/attachment.htm>

More information about the Python-Dev mailing list