Re: Importing different versions of a module
norseman
> I have two versions of a script on my machine. One version is for new
> development and the other version is a production version. This script
> imports a module from a different directory, and this module again has two
> versions (a development version and a production version). What I want is
> for the development script to import the development module, and the
> production script to import the production module, without making any
> changes to the code in the script.
>
> For example, suppose the development script is in ~/dev/rss.py, and the
> production script is in ~/prod/rss.py. I want the dev version to import
> /usr/lib/python2.5/site-packages/lib_dev/parse.py, and the prod version to
> import usr/lib/python2.5/site-packages/lib_prod/parse.py.
>
> My first instinct was to place a .pth file in ~/dev that points to
> /usr/lib/python2.5/site-packages/lib_dev, and a .pth file in ~/prod that
> points to /usr/lib/python2.5/site-packages/lib_prod, but it seems that
> site.py doesn't look at .pth files in the current working directory. My
> next attempt was to create a symbolic link in ~/dev called parse.py,
> pointing to /usr/lib/python2.5/site-packages/lib_dev/parse.py, and a
> symbolic link in ~/prod called parse.py, pointing to
> /usr/lib/python2.5/site-packages/lib_prod/parse.py, but that didn't work
> either.
>
> Can anybody suggest a way to achieve my goal? Thanks in advance.
>
>
>
> ------------------------------------------------------------------------
>
> --
> http://mail.python.org/mailman/listinfo/python-list
==========================================================
Yes, but you may not like it.
I do what you do. Prod and devel subdirs.
I store the paths in a var at the top of my programs.
I change it(them) when the program graduates.
example:
#!/usr/local....
.
.
DvlpPATH=...... #usually a full hardcoded path ending with a '/'
#FnlPATH=.....
.
.
PATH2USE=DvlpPATH #which gets changed to FnlPATH when graduating
# I keep the DvlpPATH until I'm positive I'm not
# going to send it back to school
x= os.open(PATH2USE+"pgm_or_file.ext", 'r+b')
and so forth
If the there is a need, I'll hardcode to a branch point and create sub
branch vars as needed and chain as needed.
company_one + accounting + payables + vendors
+ inventory + shelf + vendors
+ real_property + locations
company_two + (same as above)
you get the idea
YES! You do have to change the code. But in one place only once you are
correctly set.
Steve
norseman@hughesnet
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
nors...@hughes.net
Fredrik Lundh
> I have two versions of a script on my machine. One version is for new
> development and the other version is a production version. This script
> imports a module from a different directory, and this module again has
> two versions (a development version and a production version). What I
> want is for the development script to import the development module, and
> the production script to import the production module, without making
> any changes to the code in the script.
if you already have two different versions of the script, what stops you
from making changes to them?
> For example, suppose the development script is in ~/dev/rss.py, and the
> production script is in ~/prod/rss.py. I want the dev version to import
> /usr/lib/python2.5/site-packages/lib_dev/parse.py, and the prod version
> to import usr/lib/python2.5/site-packages/lib_prod/parse.py.
cannot you just insert the appropriate directory in sys.path the first
thing you do in the scripts? e.g.
import os, sys
lib = "lib_dev" # change this for prod/rss.py
sys.path.insert(0,
os.path.join(
os.path.dirname(os.__file__), "site-packages", lib
))
import parse # picks the right one
</F>
Fredrik Lundh
> It seems that you can specify the name of the module to be imported at
> runtime using the following syntax:
>
> X = __import__('X')
>
> (from http://effbot.org/zone/import-confusion.htm)
>
> Of course, I would rather specify the path to the module at runtime, not
> the module name itself, but at least this is a start...
additional approaches can be found here:
http://effbot.org/zone/import-string.htm
also see my other reply to you in this thread.
</F>
henning....@arcor.de
a shell script (bash, or CMD on Windows) and call that shell script
instead of your Python script directly?
This is probably the easiest and still a very powerful and generic
solution for this kind of problem. We do it that way regardless of the
programming language used.
Henning