__import__

[Coder Coder]

Hi,
Can someone help me with how to overload the __import__ function,
so that I can call the old __import__ function and if it cannot find
the library to be able to do something else.

- Thanks.

 

[Heiko Wundram]

Am Samstag, 8. Mai 2004 09:31 schrieb Coder Coder:

Can someone help me with how to overload the __import__ function,
so that I can call the old __import__ function and if it cannot find
the library to be able to do something else.

You shouldn't overload a builtin (at least if you expect to be compatible with
other programmers libraries), but rather do the following where you need it:

try:
import <my-package>
except ImportError:
<do something else>

Repeat after me: "Overloading a builtin is evil! Overloading a builtin is
evil!"

HTH!

Heiko.

 

[Ryan Paul]

Hi,
Can someone help me with how to overload the __import__ function,
so that I can call the old __import__ function and if it cannot find
the library to be able to do something else.

- Thanks.

The documentation has a small example of import
overload:
http://docs.python.org/lib/examples-imp.html but a better example

David Mertz (my personal hero!) does an excellent job of explaining it
simply:

""""
__import__(s [,globals=globals() [,locals=locals() [,fromlist]]])
Import the module named 's', using namespace dictionaries
'globals' and 'locals'. The argument 'fromlist' may be
omitted, but if specified as a nonempty list of
strings--e.g., '[""]'--the fully qualified subpackage will
be imported. For normal cases, the `import` statement is
the way you import modules, but in the special circumstance
that the value of 's' is not determined until runtime, use
`__import__()`.

>>> op = __import__('os.path',globals(),locals(),[''])
>>> op.basename('/this/that/other')

'other'
""" (I stole this from his web site: http://gnosis.cx/TPiP/appendix_a.txt)

He discusses usage of __import__ in his excellent essay on metaclass
programming:
http://gnosis.cx/publish/programming/metaclass_1.txt

You can also find an example in part of his 'Gnosis' library:
http://gnosis.cx/download/gnosis/magic/__init__.py

Have Fun!

 

[Ryan Paul]

Am Samstag, 8. Mai 2004 09:31 schrieb Coder Coder:

You shouldn't overload a builtin (at least if you expect to be compatible with
other programmers libraries), but rather do the following where you need it:

try:
import <my-package>
except ImportError:
<do something else>

Repeat after me: "Overloading a builtin is evil! Overloading a builtin is
evil!"

HTH!

Heiko.

nothing evil about it, as long as you just EXTEND the functionality rather
than replace it. If an overloaded import still behaves the way the rest of
the libraries expect it to, you dont break anything. If there was a risk
of dangerous compatibility issues, there wouldn't be a hook designed to
facilitate overloading it. Repeat after me: "Its ok to use a language
feature as long as I know what I am doing." ;-D

 

[Heiko Wundram]

Am Samstag, 8. Mai 2004 10:19 schrieb Ryan Paul:

"Its ok to use a language
feature as long as I know what I am doing."

Hmm... If you need to override a builtin, and do not duplicate the original
behaviour exactly (that's pretty much what the op wanted to do, anyway, if
you need to override a builtin, you're not into duplicating the original
behaviour), then you always create a can of worms whenever you use a
different package.

Say, I use: __import__("blah",{},{}), and my library expects __import__ to
throw an error in case blah can't be found, to check whether my functionality
is there or not. What the op wanted to do is to replace this check with some
deep magic, probably returning a package instead when the actual import
fails. What is my program expected to do? The import succeeds, but the
package which was actually returned isn't usable, because it doesn't
duplicate what I expect __import__("blah") to return.

It's always much, much cleaner to not override the builtin, but to create a
new method, which has the behaviour you want, and then to use that one
throughout your package. That way each programmer can rely on the fact that
the builtins work as they are specified in the language reference, and can be
sure that his/her module also works on a different machine/with different
modules, just because the underlying Python is the same.

I've had to recode a project someone else wrote, and he heavily made use of
such deep magic to create something which was a bit shorter overall, but
which was much more difficult to maintain for me later on just because
plugging in some other modules to extend the functionality simply was not
possible anymore. He also overrode __import__ to return some dummy-module in
case the one being imported wasn't found, and did even more black-magic
checks to see where the call came from using the stack-trace, and then tested
whether it was okay to return a dummy module or not. This is a maintenance
nightmare...

Heiko.