Importing different versions of a module

[norseman]

Mercado;
	Problem solved. The attached .zip file has the working example.
It is modeled after my own uses in other languages. It's not quite as 
elegant as it should be but it does work and is both flexible and 
extendable. A word of caution: I run Linux. I make no promises about any 
of my code working on Microsoft.

	Fredrik's web links on __import__ was the first major door opener. The 
use of system environmentals took a ton of google time. Search that 
proved useful was "os enviro python'. Page two had a link to a google 
book.  The Python Official Documentation does not make it clear as to 
how to use os.environ other than to note it's existence. The tutorial 
pretty much avoids it.  Python docs, in general, seem to be for (and 
maybe by) persons writing less than one page of code per project. It 
does call itself a scripting language, but it is short in sight. Don't 
get me wrong, it is useful. Just that it doesn't seem to have originally 
been given a foundation for the scale of projects I see the questions 
coming in on. A more thorough search and use of regular dictionary terms 
would have been better. In python, 'global x' means for this file, not 
for the project as is normal.

Anyway -
	Zip file has three files. .txt is test data.
				  .py is sub or called module
				  z (dot nothing) is program base

put a copy of .txt and .py in each of two locations.
   something like:
  /tmp/scott		to contain .txt and .py
  /tmp/scott/1		same

in one or the other, but not both, make a change or two to the file(s) 
there. perhaps putting 6 'Z'z in a csv field of same size following the 
12 in the last record.

put z (no last name) in maybe your home dir. anywhere but in those two.
fix the directories in both z files as needed, if needed.
enter:>  python z   and check both the source(s) and the screen.
in z change os.environ['ISTEST']='True'  to ...'False'
   and rerun.

There should be 'True' (or 'False') in the bottom of z's output and at 
the top of z.py's output. Any formatting changes and/or data changes 
should occur as expected.  Do not think you have to use these 'as-is'. 
These are just concept proof. Actual real globals (project wide) are 
still the best but, well... perhaps in time.


Gotta go to work;


Steve
norseman at hughes.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.zip
Type: application/octet-stream
Size: 2532 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-list/attachments/20080723/2b6997c3/attachment-0001.obj>