Module imports during object instantiation

Neil Cerutti horpner at yahoo.com
Tue Aug 14 14:03:55 CEST 2007


On 2007-08-14, Ritesh Raj Sarraf <rrs at researchut.com> wrote:
> Bruno Desthuilliers wrote:
>
>>>> What's leading you to conclude the import isn't being executed? You
>>>> realise, I trust, that the module's code will only be executed on the
>>>> first call to __init__()?
>>>>
>>> 
>>> Well. Putting it in a "try" inside __init__() doesn't do anything.
>> 
>> This would be highly suprising.
>>
>
> Yes, it is surprising. Unfortunately. :-(
> Or maybe I'm doing something really dumb.
>  
>>> The
>>> import never happens.
>> 
>> As soon as your running this code on a platform where os.name yields
>> either 'nt' or 'dos', the import statement is executed. You can bet your
>> ass on this. Now this import can fail for a lot of reasons (imported
>> module not in sys.path, error in the imported module, etc), and since
>> your catching *and dismissing* the ImportError, you don't know what
>> effectively happens. It's like someone send you mails, you set your
>> filter to trash mails from this person, and then complain this person
>> never send you mails !-)
>> 
>>> And thus if I make a call in any of the methods, it
>>> fails with an error message. A NameError IIRC.
>> 
>> "IIRC" ? Inspecting the traceback may help, you know.
>
> There's no traceback because the import never happens.
>
> Here's what I've captured for you exactly I see on my terminal
>
>
> rrs at learner:/tmp$ cat rick.py
> class Log:
>     def __init__(self, verbose, lock = None):
>         self.VERBOSE = bool(verbose)
>         self.lock = bool(lock)
>
>         if self.lock:
>             self.dispLock = threading.Lock()
>         else:
>             self.dispLock = None
>
>         if os.name == 'posix':
>             try:
>                 import foobar
>             except ImportError, e:
>                 print >> sys.stderr, e
>
>             self.platform = 'posix'
>             self.color = get_colors()
>
>         elif os.name in ['nt', 'dos']:
>             self.platform = 'microsoft'
>             try:
>                 import SomeModule
>             except ImportError, e:
>                 # comment out next line before going to prod...
>                 print >> sys.stderr, e
>
>                 self.color = None
>             else:
>                 self.color = SomeModule.get_colors_windows()
>         else:
>             self.platform = None
>             self.color = None
> rrs at learner:/tmp$ python
> Python 2.4.4 (#2, Jul 21 2007, 11:00:24)
> [GCC 4.1.3 20070718 (prerelease) (Debian 4.1.2-14)] on linux2
> Type "help", "copyright", "credits" or "license" for more information.
>>>> import os, sys
>>>> os.path.abspath(os.curdir)
> '/tmp'
>>>> from rick import Log
>>>> import rick
>>>> os.name
> 'posix'
>>>> import foobar
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
> ImportError: No module named foobar
>>>>
>
>
>
> For the 'posix' OS, I'm doing an erratic import which should fail and print
> the error message.
>
> See, it prints nothing. This _is_ what has made me conclude
> that imports aren't executed in __init__(). But hey, they will
> get executed if you put them in any of the methods (which is
> again illogical because methods can/are called multiple times).

If you want an import inside an __init__ to run, you must call
the __init__ function that contains it.

>>> log = rick.Log()

You'll get another surprise when you do this, though. ;)

-- 
Neil Cerutti



More information about the Python-list mailing list