RetroSearch Browse

Sat Feb 21 00:27:23 CET 2009 · http://mail.python.org/pipermail/python-dev/2009-February/086289.html

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   |   ncoghlan at gmail.com   |   Brisbane, Australia
---------------------------------------------------------------

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from http://mail.python.org/pipermail/python-dev/2009-February/086289.html below:

[Python-Dev] Choosing a best practice solution for Python/extension modules