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

Aahz aahz at pythoncraft.com
Sun Feb 22 00:46:46 CET 2009

On Sat, Feb 21, 2009, Brett Cannon wrote:

I am seeing two approaches emerging. One is where pickle contains all Python code and then uses something like useextension to make sure the original Python objects are still reachable at some point. This has the drawback that you have to use some function to make the extensions happen and there is some extra object storage. The other approach is having pickle contain code known not to be overridden by anyone, import pypickle for stuff that may be overridden, and then import pickle for whatever is available. This approach has the perk of using a standard practice for how to pull in different implementation. But the drawback, thanks to how globals are bound, is that any code pulled in from pickle/pypickle will not be able to call into other optimized code; it's a take or leave it once the call chain enters one of those modules as they will always call the implementations in the module they originate from.

To what extent do we care about being able to select Python-only on a per-module basis, particularly in the face of threaded imports? That is, we could have a sys.python_only attribute that gets checked on import. That's simple and direct, and even allows per-module switching if the application really cares and import doesn't need to worry about threads.

Alternatively, sys.python_only could be a set, but that gets ugly about setting from the application. (The module checks to see whether it's listed in sys.python_only.)

Maybe we should move this discussion to python-ideas for now to kick around really oddball suggestions?

Aahz (aahz at pythoncraft.com) <*> http://www.pythoncraft.com/

Weinberg's Second Law: If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization.

More information about the Python-Dev mailing list