> 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]
flob, pthnm, desc = imp.find_module(moduleFilename, [modulePath])
modobj = imp.load_module(moduleRealname, flob, pthnm, desc)
if flob is not None: flob.close()
Your dream example becomes:
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...