Importing different versions of a module

[norseman]

mercado mercado wrote:
> Thanks norseman for the reply.
> 
> You're right that I didn't like it though.  :-)
> 
> Also note that my original question has to do with importing modules from
> different locations.  If all I had to do was use different paths within the
> script (e.g. for sending to os.path.join or whatever), then I could just put
> those in a config file.  That's not a problem...
> 
> 
> 
> ------------------------------------------------------------------------
> 
> --
> http://mail.python.org/mailman/listinfo/python-list
===================================

I started to import a module using its path and now see what you mean.
Python is missing the concept: Programmer dictates what machine does.

(I come from assembly. If the hardware can do it, so can I.)

sys.path can be modified to switch between file sets (prod/test).
if a global is set one way, use the normal paths,
if set another, modify the needed to force the test_section into use.

Unfortunately this is not much of an answer. It means hardcoding two 
paths into globals and using a third to control which is used.  Since 
Python has a habit of coming and going on its own this may not work in a 
major effort. It may unload something and later reload with the sys.path 
set wrong. Docs say it will reload file that did load originally even if 
the file was modified between loads.  Docs do not say it keeps original 
location. I'll need some time to set things up to test what it does.

Nothing I've done in Python had bumped into your problem until I ran the
test. Never dawned on me it would be this stupid. I had intended to use 
Python to talk to ESRI products and my stuff. I made a few minor 
routines just to get used to Python and was starting to tackle the real 
problem. My assembly, C, fortran & bash scripts all work as expected.
They do, Python doesn't.



         ORIGINALLY, IN THIS REPLY, I HAD STARTED TO SAY:
I've used this before. Maybe it will work in Python, maybe not.
Global sets which section to use by being a prefix to each test module
name. Something like "my_" for test and empty otherwise.

global WHICH
WHICH='my_'

import WHICH+'subrtn'

WHICH=''

import WHICH+'subrtn2'


gets my_subrtn from the test suite
   and
gets subrtn2 from the production section.

Each module would thus need to store/reset the Global's value upon init
to be used in its own imports since it's status at any given time is in
question.

Python docs say Python keeps the original name of the originally
successfully loaded file. The built-in 'reload' can get it back, even if
it has been changed (edited) during the session.

The files my_ whatever have the my_ removed from the disk name when they
go production.
#########################################################
                           BUT!!!!
import WILL NOT TAKE VARS!!!!!!!!
#########################################################

OK   check#1
Python 2.5.2 (r252:60911, Mar  4 2008, 10:40:55)
[GCC 3.3.6] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> WHICH="my_"
>>> import WHICH+"popen2"
   File "<stdin>", line 1
     import WHICH+"popen2"
                 ^
SyntaxError: invalid syntax
>>>
OK  check#2
>>>
>>> x=WHICH+"open2"
>>> x
'my_open2'
>>> import x
Traceback (most recent call last):
   File "<stdin>", line 1, in <module>
ImportError: No module named x
>>>
OK   check#3
>>>
>>> help(x)
no Python documentation found for 'my_open2'    #true, proves x OK
>>>

BOY-O-BOY,  DOES THAT SCREW THE POOCH!!!!

Mercado, like you, I'm not very happy right now.  This means that
prefixing cannot be used to control imports. For decades I have used 
prefixing in both scripts and compiled lib routines for controlling what 
gets loaded or not.

Right now I'm not a happy Python camper, not at all.



Steve
norseman at hughes.net