__import__

Discussion in 'Python' started by Coder Coder, May 8, 2004.

  1. Coder Coder

    Coder Coder Guest

    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.
    Coder Coder, May 8, 2004
    #1
    1. Advertising

  2. 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.
    Heiko Wundram, May 8, 2004
    #2
    1. Advertising

  3. Coder Coder

    Ryan Paul Guest

    On Sat, 08 May 2004 00:31:58 -0700, Coder Coder wrote:

    > 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, May 8, 2004
    #3
  4. Coder Coder

    Ryan Paul Guest

    On Sat, 08 May 2004 09:40:39 +0200, Heiko Wundram wrote:

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


    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
    Ryan Paul, May 8, 2004
    #4
  5. 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.
    Heiko Wundram, May 8, 2004
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Marco Herrn

    __import__() with packages

    Marco Herrn, Apr 4, 2004, in forum: Python
    Replies:
    5
    Views:
    431
    Hung Jung Lu
    Apr 6, 2004
  2. bwobbones

    usage of __import__ across two files

    bwobbones, Dec 12, 2004, in forum: Python
    Replies:
    1
    Views:
    283
    John Roth
    Dec 12, 2004
  3. bwobbones
    Replies:
    1
    Views:
    329
    Diez B. Roggisch
    Dec 13, 2004
  4. Wensheng
    Replies:
    2
    Views:
    307
    Jeff Shannon
    Feb 10, 2005
  5. Phil
    Replies:
    2
    Views:
    454
Loading...

Share This Page