Brett Cannon 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.
Ah, you may want to think about that a bit more. There's a reason globals are looked up when they're used rather than when their function is defined. Even in your own example, _B isn't defined at all when you define A. There is a (real) related problem whereby the Python version will *use* it's own globals if it actually tries to call any functions during the import, but that's a problem shared by any "overwrite at the end of import" approach to swapping in extension module versions of functions. With appropriate __all__ definitions in the C extension modules, I don't see anything wrong with Daniel's suggested approach. Note also that with this approach _io.__all__ will give the details of what has been overridden by the extension module, so it even still provides a decent level of introspection support. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --------------------------------------------------------------- _______________________________________________ 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
