Import question

[Alex Martelli]

"Costas Menico" <costas at meezon.com> wrote in message
news:3b079db8.598167 at News.CIS.DFN.DE...
    ...
> There is a solution for both issues you raise in my dream Python.
>
> Assume there is a myfile.ini file and an ini file reader that allows
> you to configure your system at installation time.
>
> import ini
> aPath1 = ini.getIni('path1','myfile.ini')
> aPath2 = ini.getIni('path2','myfile.ini')
>
> import aPath1 + 'peep' as peep1
> import aPath2 + 'peep' as peep2

And this would affect sys.modules how...?  Remember, the
'as' only affects the CURRENT binding of a module object,
NOT the way in which it's recorded in sys.modules.


> Of course the syntax above is bogus since import does not accept an
> expression for the module name. And the reload() would also work with
> no changes.

Syntax sugar is no biggie.  _AVOIDING_ undesired reload seems
the (relatively) biggie:-).

Anyway, here, syntax-sugar details apart, is your "dream Python
importer" -- place it in builtins in your site.py, or whatever:

import imp, sys
def CMimport(modulePath, moduleFilename, moduleRealname=None):
    if moduleRealname is None: moduleRealname = moduleFilename
    try: return sys.modules[moduleRealname]
    except KeyError:
        flob, pthnm, desc = imp.find_module(moduleFilename, [modulePath])
        try:
            modobj = imp.load_module(moduleRealname, flob, pthnm, desc)
        finally:
            if flob is not None: flob.close()
        return modobj

Your dream example becomes:

import ini
aPath1 = ini.getIni('path1','myfile.ini')
aPath2 = ini.getIni('path2','myfile.ini')

peep1 = CMimport(aPath1, 'peep', 'peep1')
peep2 = CMimport(aPath1, 'peep', 'peep2')

Close enough for you...?  If you want to suggest this as a core built-in
or something, feel free to use this trivial code in the patch you'll submit
to Sourceforge.  As for me, I'm quite happy to use the standard import
on the 99+% of occasions where it serves me just fine, since it's about
5 minutes to do my own importing tricks (such as this one) on the
less than 1% of cases where I prefer non-standard behavior.

This doesn't support packages, BTW -- that takes more work.  And I
hope you'll agree packages are best left to their current behavior, in
any case (otherwise, you'll welcome to extend this to support them!).


> Another advantage is the fact that you are specific about which module
> to load. Without the path name you can have in your sys.path two
> modules of the same name and un-intenionally load the wrong one. A
> more insidious problem than hardwiring.

Just like for the system PATH, &c, I see this not as "an insidious problem"
but as an important technique for temporarily substituting a polymorphic
version of some existing program/module/&c for debugging purposes.

> P.s. I don't believe hardwiring is the domain of "less advanced"
> users. I do it all the time for throwaway code as I am sure you have.

Yes, but NOT for code intended to be distributed (sort of the reverse
of "throwaway"!-), which was part of my point -- since it's so easy to
tweak importing behavior, if you often rely on this tweak _for your
own throwaway programs_ just install it from your site.py -- the only
'advantage' of having it as default behavior would be if the technique
was worth supporting in programs intended for wide distribution...


Alex